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ABSTRACT 


This  report  presents  a  detailed  description  of  a  computer  simulation 
package  designed  for  the  Great  Lakes-St.  Lawrence  Seaway  navigation  system. 
The  discussion  is  divided  into  three  parts  corresponding  to  the  major 
components  of  the  simulation  package.  Part  I  covers  NETSIM  II,  the  simula¬ 
tion  program  itself.  Part  II  covers  PROSIM,  the  statistical  report  generator 
for  NETSIM  II.  Each  of  these  programs  is  written  in  SIMSCRIPT  and  each  is 
composed  largely  of  subroutines  which  carry  out  processing  for  the  various 
kinds  of  navigation  facilities.  This  modular  structure  greatly  simplifies 
the  task  of  program  modification.  Part  III  describes  four  FORTRAN  programs 
which  have  been  provided  to  facilitate  data  preparation  for  NETSIM  II. 
Detailed  user  manuals  are  included  for  all  programs  in  the  package. 

The  model  is  addressed  to  the  task  of  analyzing  the  performance  of  a 
waterway  system  under  various  structural  and  nonstructural  improvements. 

The  analysis  is  in  terms  of  delays,  congestion  and  utilization.  The  major 
feature  of  the  model  is  its  ability  to  simulate  traffic  flows  which  result 
from  a  given  pattern  of  transport  demand  (commodity  movements). 
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The  work  described  in  this  report  was  performed  by  The  Pennsylvania 
Transportation  and  Traffic  Safety  Center  (PTTSC)  at  the  Pennsylvania  State 
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This  report  is  the  fourth  in  a  series  of  four  volumes  documenting  the 
development  and  application  of  a  computer  model  for  the  simulation  of  the 
Great  Lakes  and  St.  Lawrence  Seaway  navigation  system.  Other  titles  in 
this  series  are  as  follows: 

Volume  1  NETSIM:  A  General  Network  Simulator 

Volume  2  Lake  Erie-Lake  Ontario  Navigation: 

A  Simulation  Study  of  Alternative 
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CHAPTER  1.  INTRODUCTION 


A.  GREAT  LAKES-ST.  LAWRENCE  WATERWAY  SYSTEM 

In  June  of  1972,  the  Army  Corps  of  Engineers,  North  Central  Division, 
entered  into  a  contract  with  the  Pennsylvania  Transportation  and  Traffic 
Safety  Center  (PTTSC)  for  the  development  of  a  simulation  model  that  would 
facilitate  a  systematic  analysis  of  the  capacity  of  the  Great  Lakes-St. 
Lawrence  Waterway  System  (GL-SLS).  The  development  of  this  simulation  model 
has  been  carried  out  in  three  phases: 

1.  development  of  a  Lake  Erie-Lake  Ontario  (LE-LO)  Navigation 
Simulation  model; 

2.  application  of  the  LE-LO  model  to  simulation  studies  of  the 
Welland  Canal  and  proposed  alternatives  to  the  Welland; 

3.  revision  of  the  LE-LO  model  to  include  the  capabilities 
needed  for  comprehensive  GL-SLS  system  simulations. 

The  simulation  program  (NETSIM  II)  described  in  this  report  represents 
the  completion  of  the  third  phase.  The  efforts  in  upgrading  the  LE-LO  model 
have  been  directed  specifically  at  creating  a  GL-SLS  simulation  model.  That 
is,  flexibility  was  maintained  wherever  possible,  but  overall,  the  program 
has  clearly  been  tailored  to  the  special  structure  of  the  GL-SLS. 

The  Great  Lakes-St.  Lawrence  Waterway  System  consists  of  the  St. 
Lawrence  River,  the  five  Great  Lakes  (Lakes  Superior,  Michigan,  Huron,  Erie, 
and  Ontario),  Lake  St.  Clair  and  several  connecting  channels,  including  the 
Welland  Canal.  Since  the  system  is  linked  to  the  Atlantic  Ocean  by  the  St. 
Lawrence  River,  it  serves  not  only  for  intrasystem  commodity  movements,  but 
for  trade  with  saltwater  ports  outside  the  system  as  well. 
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The  lakes  are  relatively  uncongested  and  allow  free  movement  of 
vessels  on  them.  Width  and  depth  of  some  of  the  reaches,  however,  along 
with  traffic  regulations,  provide  significant  constraints  to  vessel  speeds. 
Further,  the  locks  in  the  St.  Lawrence  River,  the  Welland  Canal  and  at 
Sault  Ste.  Marie  are  potentially  serious  impediments  to  traffic  flows. 

B.  THE  NETSIM  II  SIMULATION  PROGRAM 

Historically,  development  of  NETSIM  II  dates  back  to  the  use  of 
computerized  simulation  models  on  the  inland  waterways.  The  circumstances 
leading  to  their  development  and  the  results  of  that  research  are  reported 
in  a  six-volume  technical  report  entitled  Waterway  Systems  Simulation  [1,  2, 
3,  4,  5,  6].  The  groundwork  for  the  current  model  was  laid  In  Volume  V  of 
this  series,  entitled  Simulation  of  Multiple  Channel  Deep  Draft  Navigation 
Systems  [5]. 

In  NETSIM  II,  the  sophistication  of  the  locking  routines  in  particular 
is  in  large  part  due  to  the  earlier  research.  In  fact,  the  lock  routines 
in  NETSIM  II  have  been  simplified  somewhat  from  those  of  its  predecessor 
(the  LE-LO  model),  as  it  was  felt  that  such  a  detailed  micro  model  of  the 
locks  was  unnecessary  in  this  more  comprehensive  system  simulation. 

The  experience  data  bank  (EDB)  concept  used  in  NETSIM  II  was  developed 
in  the  Multiple  Channel  Deep  Draft  Navigation  Systems  study.  In  this 
approach,  a  run  of  the  simulation  model  itself  produces  data  from  which 
expected  transit  times  through  a  route  segment  can  be  estimated  based  upon 
system  conditions.  The  estimation  equation  is  then  used  in  subsequent  runs 
as  the  criterion  for  a  vessel's  choice  between  parallel  route  segments. 

That  is,  whenever  a  vessel  is  confronted  with  a  choice  between  two  parallel 
routes  to  the  same  destination,  the  alternative  which  offers  the  lower 
expected  transit  time  will  be  chosen. 
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The  primary  capability  which  has  been  added  to  the  LE-LO  model  in 
order  to  give  NETSIM  II  the  capacity  for  systems  simulation  is  a  vessel 
scheduling  mechanism.  Whereas  the  LE-LO  model  required  a  schedule  of 
vessel  movements  as  input  data,  NETSIM  II  develops  these  schedules 
dynamically  based  upon  the  requirements  for  commodity  transport.  This 
dynamic  scheduling  capability  allows  study  of  such  matters  as  vessel 
fleet  requirements,  efficiency  of  various  scheduling  rules  and  implications 
of  hypothetical  changes  in  the  mix  of  commodity  flows. 

NETSIM  II  has  retained  flexibility  in  two  respects.  First,  it  is 
written  in  a  powerful  language — SIMSCRIPT — with  its  logic  modularized  to 
a  great  degree.  This  means  that  modifications  to  one  aspect  of  the  model 
(e.g. ,  calculation  of  transit  times  across  lakes)  can  often  be  made  by 
altering  only  one  or  two  subroutines  and  leaving  the  rest  of  the  program 
untouched.  Second,  the  model  can  simulate  networks  of  virtually  any  reason¬ 
able  size  and  configuration.  This  means  that  the  program  can  accommodate 
the  entire  GL-SLS  or  any  part  of  it.  Also,  the  number  of  ports,  locks, 
etc.,  to  be  included  may  be  changed  at  will.  The  only  constraint  on  system 
size  is  the  amount  of  computer  core  memory  and  run  time  available.  Require¬ 
ments  for  auxiliary  input/output  devices  are  modest. 

The  primary  output  of  NETSIM  II  is  an  event  log,  which  consists  of  a 
separate  detail  record  for  every  event  of  interest  which  occurs  during  the 
course  of  the  simulation.  Here,  by  "event”  is  meant  such  status  changes  as 
"vessel  enters  berth",  "vessel  exits  lock  chamber",  "vessel  enters  queue 
for  berth"  or  "vessel  departs  reach".  These  data  in  their  raw  form  are 
rather  incomprehensible,  so  a  separate  SIMSCRIPT  program,  PROSIM,  has  been 
provided  to  process  the  event  log  data  and  produce  meaningful  reports  for 
the  user. 
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In  addition  to  NETSIM  II  and  PROSIM,  the  simulation  package  includes 
a  number  of  auxiliary  programs  for  input  data  preparation.  These  facili¬ 
tate  such  tasks  as  preparation  of  vessel  fleet  data  and  arrivals  of 
commodities  (overland)  into  ports.  Although  they  are  quite  independent  of 
the  NETSIM-PROSIM  model,  the  auxiliary  programs  have  been  written  in  such 
a  way  as  to  coordinate  directly  with  the  use  of  the  model. 

The  remainder  of  Part  I  of  this  report  describes  NETSIM  II  in  detail. 
The  following  sections  deal  with  program  input  requirements,  program  logic, 
program  outputs  and,  finally,  testing  and  calibration.  Appendix  A  Is  a 
NETSIM  II  user  manual  and  Appendix  B  contains  an  example  problem. 


CHAPTER  2.  INPUT  DATA 

This  chapter  describes  the  classes  of  input  data  required  by  NETSIM  II. 
The  description  includes  enumeration  of  all  major  categories  of  input  data 
and  some  discussion  of  their  use  within  the  program.  Detailed  card  format 
specifications  may  be  found  in  Appendix  A,  and  Appendix  B  provides  a  list¬ 
ing  of  input  data  for  an  example  problem. 

The  input  to  NETSIM  II  is  made  up  of  the  following  basic  data  groups 
(illustrated  in  Figure  2-1)  listed  in  sequential  order  as  they  would  be 
read  in  by  the  program: 

(1)  run  parameters; 

(2)  description  of  the  navigation  facilities; 

(3)  description  of  the  navigation  network; 

(4)  commodity  arrival  list  at  ports; 

(5)  vessel  fleet  data; 

(6)  itineraries  for  saltwater  vessels. 

Each  of  these  classes  is  treated  in  the  following  sections. 

A.  RUN  PARAMETERS 

This  class  of  data  includes  the  following  items: 

(1)  length  of  the  season  to  be  simulated  in  minutes; 

(2)  run  options; 

(3)  input-output  devices; 

(4)  system  size  parameters; 

(5)  vessel  classification  parameters. 
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Figure  2-1.  System  Structure 
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Item  1  controls  the  total  simulation  run  time  and  must  be  large 
enough  to  provide  the  user  with  a  steady  state  simulation  for  the  desired 
period.  At  the  beginning  of  the  simulation,  the  waterway  system  is  allowed 
to  start  in  an  empty  condition  and  a  finite  amount  of  time,  referred  to  as 
the  warm-up  or  transient  time,  is  usually  necessary  for  the  system  to 
reach  steady  state  operation.  So  if  it  is  desired  to  simulate  a  period  of 
30  days  with  a  warm-up  time  of  4  days ,  the  simulation  run  time  T  should  be 
set  at 

T  -  1440  x  34 

where  the  warm-up  time  has  been  added  to  the  desired  simulation  period. 

Item  2  specifies  run  type  options.  These  include  options  for  an 
experience  Data  Bank  (EDB)  run,  use  of  the  service  look-ahead  feature  and 
a  code  for  the  existence  of  parallel  route  options  in  the  waterway  network. 

Item  4  allows  the  program  to  set  up  its  entity  set  structures  by 
defining  the  number  of  ports,  locks,  reaches,  lakes,  nodes  and  commodity 
types  in  the  system.  Certain  other  parameters,  used  mainly  as  pointers  in 
the  program  are  also  included  under  this  category. 

Item  5  provides  length  and  horsepower  delineations  for  vessel  classi¬ 
fications.  These  data  are  used  in  the  program  to  adjust  some  average  vessel 
processing  times  by  vessel  attributes. 

B.  DESCRIPTION  OF  THE  NAVIGATION  FACILITIES 

This  class  of  data  provides  descriptions  of  ports,  lakes,  reaches  and 
locks  in  sequential  order  as  required  by  the  program. 


These  features  are  fully  described  in  the  next  chapter. 
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1.  Ports 


A  port  is  defined  as  a  navigation  facility  on  the  waterway  at  which 
vessels  may  discharge  and/or  receive  all  or  part  of  their  cargoes.  Due  to 
their  unique  position  as  areas  of  transaction  where  the  supply  and  demand 
of  transportable  commodities  and  transport  equipment  units  interact,  pre¬ 
sumably  towards  some  equilibrium  to  be  determined  during  the  simulation, 
ports  are  accorded  a  distinct  treatment  in  NETSIM  II.  Specifically,  the 
port  routines  contain  the  logic  for  dynamic  vessel  scheduling  which  assigns 
a  vessel  to  its  next  destination  based  on  the  current  location  of  the  vessel 
in  the  system,  the  cargo  carrying  capabilities  of  the  vessel,  the  cargo 
inventories  and  requirements  at  ports,  and  the  proportion  of  empty  movements 
on  a  particular  route. 

In  accordance  with  the  special  treatment  given  to  ports,  the  data  needs 
are  also  more  complex.  The  port  data  must  include  physical  description  by 
means  of  a  port  identification  number,  depth,  and  the  number  of  berths  avail 
able  for  loading  and  unloading  cargo  for  each  of  four  cargo  types:  general 
cargo,  liquid  bulk,  dry  bulk  excluding  grain,  and  grain.  Also  for  each 
cargo  type,  the  average  loading  and  unloading  rates  and  the  standard  devia¬ 
tions  must  be  given.  For  each  commodity  type^,  the  probability  of  empty 
backhaul  occurrences  is  required. 

A  certain  minimum  amount  of  cargo  must  be  available  to  qualify  for 
loading  onto  a  vessel.  This  minimum  cargo  level  for  general,  dry  bulk  and 
liquid  bulk  cargo  must  be  specified.  If  no  minimum  load  is  available  at  a 
port,  inquiry  can  be  made  at  one  or  more  nearby  ports  to  determine  whether 


Note  the  distinction  between  commodity  type  and  cargo  types.  There  are 
only  four  cargo  types  in  NETSIM  II  as  noted  above.  Within  the  dry  bulk 
cargo  type,  however,  there  may  be  distinct  commodities. 
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a  suitable  cargo  is  available  there.  These  nearby  ports  must  be  specified 
for  each  port.  The  user  can  also  specify  the  maximum  queue  levels  of 
vessels  waiting  to  be  assigned  a  cargo  at  any  port  before  arriving  vessels 
are  sent  back  to  their  origins  empty  after  being  unloaded. 

The  port  data  also  include  a  vessel  loading  factor  which  serves  as  a 
calibration  factor,  commodity  arrival  rates  referred  to  as  cargo  influx 
rates  in  the  program  and  used  in  the  dynamic  scheduling  procedures,  and 
finally  a  lower  bound  for  port  turnaround  time,  i.e.,  the  minimum  time  to 
enter  and  exit  the  port. 

In  summary,  the  port  data  consist  of  the  following  items: 

(1)  vessel  loading  factor; 

(2)  minimum  cargo  levels; 

(3)  port  identification; 

(4)  lower  bound  for  port  turnaround  time; 

(5)  cargo  influx  rates; 

(6)  depth; 

(7)  nearby  ports; 

(8)  unloading  rates ; 

(9)  loading  rates; 

(10)  standard  deviations  for  port  turnaround  time; 

(11)  cargo  queue  limits; 

(12)  number  of  berths  available; 

(13)  probabilities  of  empty  backhaul. 

Items  4,  8,  9  and  10  are  used  in  the  calculation  of  port  turnaround 
times . 
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2.  Lakes 


This  class  of  data  includes  the  following  items: 

(1)  Physical  description 

(a)  lake  identification; 

(b)  number  of  nodes  on  the  lake; 

(c)  code  to  indicate  presence  of  parallel  routes. 

(2)  Intralake  travel  table  -  an  origin-destination  (0-D)  travel 
time  matrix  for  all  nodes  on  the  lake. 

As  an  alternative  to  the  travel  table,  the  user  is  allowed  to  specify 
the  use  of  a  theoretical  distribution. 

3.  Reaches 

This  class  of  data  includes  the  following  items: 

(1)  Physical  description 

(a)  reach  identification; 

(b)  reach  length; 

(c)  code  to  indicate  whether  passing  is  permitted; 

(d)  code  to  indicate  presence  of  parallel  routes; 

(e)  code  to  indicate  theoretical  or  empirical  transit 
time  distribution; 

(f)  upstream  node; 

(g)  downstream  node. 

(2)  Transit  time  distribution  -  either  theoretical  or  empirical. 

(3)  Expected  transit  time  (ETT)  function  for  each  direction  of 
travel  if  there  are  parallel  routes  (as  indicated  in  Item  Id). 

The  ETT  functions  are  not  supplied  for  an  EDB  run. 


I 
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4.  Locks 


The  lock  data  consist  of  four  main  segments:  physical  description, 
locking  time  frequency  distributions,  adjustment  factors  for  these  dis¬ 
tributions,  and  ETT  functions. 

Physical  description  of  locks  consists  of  the  following  items: 


(1) 

lock  identification; 

(2) 

upstream  node; 

(3) 

downstream  node; 

W 

maximum  vessel  length  accommodated  in 

lock; 

(5) 

code  to  indicate  presence  of  parallel 

routes ; 

(6) 

codes  to  indicate  theoretical  or  empirical  locking 

time  distributions. 

For  simulation  purposes,  the  locking  operation  in  NETSIM  II  is  broken 
Into  five  segments  as  shown  in  Figure  2-2 3.  Each  of  these  segments  requires 
either  theoretical  or  empirical  probability  distributions. 

The  third  category  of  lock  data  consists  of  adjustment  factors  for 
each  of  the  five  locking  segments.  These  factors  are  used  in  NETSIM  II  to 
modify  the  distribution  sampled  value  by  vessel  attributes.  The  exact 
modification  performed  within  the  program  is  dependent  on  the  vessel 
classification  parameters. 

The  final  item  under  lock  data  consists  of  an  ETT  function  for  each 
direction  of  travel.  These  functions  are  only  provided  if  a  lock  is  part 
of  a  parallel  route  set  and  they  are  then  used  in  the  program's  channel 
choice  mechanism.  The  ETT  functions  are  not  provided  for  an  EDB  run. 


3 

In  NETSIM  I,  the  locking  operation  consists  of  nine  distinct  elements  (see 
Ref.  [1]  ).  The  higher  degree  of  aggregation  in  NETSIM  II  accrues  from 
more  critical  space  and  computer  time  constraints. 


Figure  2-2.  Locking  Time  Segments 
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C.  DESCRIPTION  OF  THE  NAVIGATION  NETWORK 


This  class  of  data  provides  NETSIM  II  with  a  complete  map  of  the 
waterway  being  simulated  and  operationally  consists  of  three  matrices. 

These  matrices  are  called  the  table  of  next  nodes,  the  facilities  id  table 
and  the  parallel  facilities  table. 

1.  Table  of  Next  Nodes 

The  table  of  next  nodes  gives  the  intermediate  node  between  each  node¬ 
port  pair  in  the  system.  Structurally,  this  is  a  m  x  n  matrix  where  m  is 
the  number  of  nodes  and  n  is  the  number  of  ports.  Thus,  each  cell  in  the 
matrix  contains  the  next  node  encountered  in  traveling  from  the  i*"*1  node 
to  the  j1"*1  port.  In  the  event  that  parallel  routes  are  present,  the  entry 
in  the  table  of  next  nodes  is  a  pointer  to  the  parallel  facilities  table 
which  lists  the  alternatives  available. 

2.  Facilities  Id  Table 

The  facilities  id  table  gives  the  intermediate  facility  between  each 
pair  of  nodes  in  the  system.  This  matrix  is  illustrated  in  Figure  2-3  for 
a  system  with  m  nodes.  Since  this  matrix  is  symmetrical  with  the  cells 
in  the  main  diagonal  being  empty,  the  user  is  required  to  supply  only  the 
lower  triangle  of  the  matrix,  as  shown  in  the  figure. 

3.  Parallel  Facilities  Table 

Simulation  of  a  system  with  parallel  route  options  in  NETSIM  II  requires 
first,  a  complete  listing  of  each  route  option  in  terms  of  facilities  and 
nodes  and  second,  a  mechanism  to  select  one  route  over  the  other  at  any 
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NODES 


NODES 


P  ^  ^Facility  between  i  and  j  where  i  and  j  are  consecutive  nodes 
ij  where  i  and  j  are  not  consecutive  nodes 


Figure  2-3.  Facilities  ID  Table 


given  time  during  the  simulation.  These  requirements  are  met  by  the  pro¬ 
vision  of  the  parallel  facilities  table.  Since  routes  may  not  necessarily 
be  of  the  same  length,  this  matrix  is  a  two-dimensional  jagged  array  which 
provides  the  route  description  and  the  ETT  function  for  each  route  option. 
Figure  2-4  illustrates  this  table. 


D.  COMMODITY  ARRIVAL  LIST  AT  PORTS 

The  commodity  arrival  list  at  ports  constitutes  an  external  event  list 
in  NETSIM  II  and  thus  requires  a  special  format  using  the  external  event 
data  notices  (cards).  Each  notice  supplies  NETSIM  II  with  various  cargo 
shipments  introduced  at  various  ports.  All  shipments  within  a  notice 
arrive  at  their  ports  at  the  same  simulation  time,  however.  Each  shipment 
is  described  in  terms  of  the  following: 

(1)  port  number  into  which  the  commodity  is  to  be  introduced 

(2)  commodity  type 

(3)  destination 

(4)  quantity. 

Normally,  the  user  will  wish  to  store  this  list  on  a  separate  card 
or  tape  file. 


E.  VESSEL  FLEET  DATA 

Vessels  are  introduced  into  the  system  as  exogenous  events  in  NETSIM  II, 
thus,  the  vessel  data  must  also  be  supplied  through  the  external  event  data 
notices.  Each  notice  provides  data  for  attributes  of  a  single  vessel  and 
must  describe  the  following: 

(1)  simulation  time  at  which  vessel  enters  system 

(2)  number  of  the  port  at  which  the  vessel  is  to  be  introduced 
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Description 

Route  3 

Description 

ETT  Function  for  Route  1 

ETT  Function  for  Route  2 

ETT  Function  for  Route  3 

Figure  2-4.  Parallel  Facilit 
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(3)  length 

(4)  horsepower 

(5)  capacity 

(6)  unloading  rate  (for  self-unloaders  only) 

(7)  draft 

(8)  classification 

(9)  code  to  indicate  backhaul  journey 

(10)  commodity  tonnage 

(11)  commodity  type 

(12)  origin 

(13)  identification  number 

Normally,  the  user  will  wish  to  store  these  data  on  a  separate  card 
or  tape  file. 

F.  ITINERARIES  FOR  SALTWATER  VESSELS 

Scheduling  of  saltwater  vessels  is  handled  quite  differently  from 
that  of  local  bulk  vessels  in  NETSIM  II.  The  saltwater  vessels  enter  the 
system  from  the  Atlantic  Ocean  with  predetermined  itineraries.  That  is, 
the  exact  sequence  of  ports-of-call  has  been  arranged  before  the  vessel 
enters  the  system.  To  reflect  this  situation  NETSIM  II  reads  in  a  new 
itinerary  to  assign  to  each  saltwater  vessel  as  it  is  introduced  into  the 
system. 

An  itinerary  consists  of  the  following: 

1.  the  number  of  ports-of-call, 

2.  for  each  port-of-call 

(a)  the  port  number, 

(b)  the  fraction  of  the  vessel's  cargo  capacity  to  be 
loaded  at  this  port. 
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(c)  Che  fraction  of  Che  vessel's  cargo  capacity  Co  be 
unloaded  at  this  port. 

In  NETSIM  II,  everything  external  to  the  navigation  system  (beyond 
the  entrance  to  the  St.  Lawrence  River)  is  given  a  single  port  number.  We 
may  refer  to  this  as  the  "Atlantic  Port."  On  any  saltwater  vessel  itinerary, 
the  Atlantic  Port  must  be  the  last  port-of-call. 


CHAPTER  3.  LOGIC  AND  OPERATIONS 


This  chapter  describes  the  actual  operations  followed  by  NETSIM  II 
in  simulation  processing.  The  main  objective  here  is  to  provide  the 
reader  with  an  overall  perspective  of  the  logic  and  assumptions  underlying 
the  program.  A  highly  detailed  description  of  the  programming  considera¬ 
tions  is  not  presented  here;  complete  program  documentation  has  been 
furnished  separately  to  the  Contracting  Officer.^" 


A.  PROGRAM  OVERVIEW 

Before  presenting  NETSIM  II’s  entity,  event  and  routine  structures, 
a  brief  explanation  of  the  overall  global  strategy  is  in  order.  This 
strategy  is  closely  tied  into  SIMSCRIPT's  programming  capabilities.  A 
reader  familiar  with  SIMSCRIPT  may  therefore  wish  to  skim  over  this 
section  and  concentrate  on  particular  features  of  NETSIM  II. 

The  basic  unit  of  action  in  NETSIM  II  is  a  change  in  the  status  of 
an  entity  such  as  a  vessel,  lock,  port,  etc.  These  status  changes  may 
involve  physical  movement  of  a  vessel  from  one  point  of  the  network  to 
another  or  they  may  represent  the  accumulation  of  idle  time  as  delay. 

The  exact  sequence  in  which  changes  occur  and  their  effects  on  the  system 
are  characterized  by  events  which  are  modeled  in  NETSIM  II  as  subprograms 
and  which  are  executed  in  zero  simulated  time,  i.e.,  events  representing 
status  changes  occur  Instantaneously. 


*A11  requests  for  listings,  program  decks,  flow  charts,  etc.,  should  be 
directed  to  the  Contracting  Officer. 


Two  classes  of  events  are  possible  in  NETSIM  II.  Exogenous  events 
are  events  fed  to  the  model  externally.  Commodity  arrivals  at  ports  during 
the  simulation  and  vessel  introductions  into  the  system  are  exogenous 
events.  These  events  are  fed  to  the  program  from  an  external  data  source 
(magnetic  tape  or  disk,  punched  cards,  etc.).  Endogenous  events  are  events 
generated  within  the  program.  There  are  numerous  endogenous  events  in 
NETSIM  II  and  during  the  course  of  the  simulation  many  schedule  each  other. 
For  example,  the  event  for  a  vessel  to  exit  queue  at  a  lock  may  upon  its 
consummation  schedule  an  event  to  enter  the  lock  chamber.  An  event  for  a 
vessel  to  exit  a  lake  may  schedule  an  event  for  this  vessel  to  enter  the 
next  reach. 

Keeping  track  of  the  simulated  time  is  accomplished  automatically  by 

SIMSCRIPT' s  timing  routine.  This  is  a  special  routine  which  accepts 

requests  for  the  execution  of  events  at  specified  future  times  and  organizes 

them  so  that  the  event  routines  (subprograms)  are  called  in  the  order  of 

their  scheduled  event  times.  The  simulation  clock  is  advanced  by  the  timing 

2 

routine  from  one  event  time  to  the  next  in  chronological  order. 

Entities  in  SIMSCRIPT  may  either  be  permanent  or  temporary ,  the  main 
distinction  of  relevance  here  being  that  temporary  entities  can  be  created 
and  destroyed  individually  at  various  times  during  the  simulation.  Ports, 
reaches,  lakes  and  locks  are  permanent  entities  in  NETSIM  II  while  vessels 
are  the  main  temporary  entities.  Both  types  of  entities  have  attributes 
and  sets  and  can  have  owner-member  relationships  with  each  other.  In  these 
terms,  simulation  in  NETSIM  II  can  be  simply  described  as  the  filing  in  sets, 

2 

The  simulation  clock  is  advanced  in  discrete  time  increments  which  are 
not  necessarily  uniform;  hence  SIMSCRIPT  is  referred  to  as  a  discrete 
simulation  language. 
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processing  and  removing  from  sets  of  the  temporary  entities  (vessels) 
which  are  owned  by  the  permanent  entities.  These  operations  must  be 
carried  out  in  an  orderly  manner  as  determined  by  transport  supply  and 
demand . 

B.  SIMULATION  PROCESSING 

The  network  of  interest  is  represented  in  NETSIM  II  as  a  system  of 
links  and  nodes.  Reaches,  lakes  and  locks  constitute  the  links,  while 
ports  and  link  interfaces  are  the  nodes.  A  simulation,  then,  involves 
representing  the  movements  of  vessels  among  and  through  these  fixed 
facilities  of  the  network. 

1.  Initialization 

NETSIM  II  begins  simulation  by  referencing  the  initialization  routine 
which  reads  all  the  input  data  and  the  first  event  records  on  the  exogenous 
events  input  sources.  Little  processing  of  the  input  values  occurs  since 
the  model  uses  the  data  in  raw  form.  The  data  are  used  to  set  up  NETSIM  II' 
entity  set  structures  and  system  map  matrices. 

The  initialization  routine  makes  some  data  validity  checks  but  these 
are  minimal  in  nature.  Since  most  of  the  input  data  are  read  in  free  form 
(i.e.,  without  fixed  format),  omission  of  a  particular  item  will  normally 
result  in  some  SIMSCRIPT  error  message  for  type,  form  or  volume  of  the 
data,  resulting  in  program  termination.  Therefore,  it  would  behoove  the 
user  to  be  prudent  in  his  data  handling  efforts  and  to  fully  eliminate  all 
input  errors. 

When  all  the  data  are  read  in,  the  initialization  routine  is  released 
from  computer  memory  since  it  is  no  longer  required  for  the  simulation. 
Control  is  then  passed  to  the  timing  routine  which  acts  upon  the  earliest 


scheduled  exogenous  event  and  references  the  appropriate  event  routine. 


2.  Movement  Control 

The  actual  simulation  begins  with  the  processing  of  the  two  exogenous 
events,  commodity  arrivals  and  vessel  introductions.  Both  of  these  events 
occur  within  the  realm  of  the  port  function,  as  will  be  explained  later, 
with  the  eventual  result  that  a  vessel  equipped  with  a  cargo  and  a  destina¬ 
tion  embarks  on  its  journey.  Its  movement  through  the  network  is  governed 
by  the  movement  control  routine. 

Vessels  may  be  of  two  general  classifications.  U.  S.  and  Canadian  bulk 
carriers  are  strictly  local  to  the  system.  They  carry  no  general  cargo  and 
they  never  leave  the  Seaway  for  overseas  ports .  During  simulation  their 
movements  are  determined  dynamically  by  the  destinations  of  cargoes  available 
at  ports.  Saltwater  vessels,  on  the  other  hand,  enter  the  Seaway  (from  the 
Atlantic  Ocean)  with  predetermined  itineraries.  Each  itinerary  lists  the 
allowed  ports-of-call  for  the  vessel.  These  vessels  carry  general  cargo  as 
well  as  overseas  bulk  commodity  shipments  and  are  created  and  destroyed  as 

3 

they  enter  and  leave  the  system  (via  the  St.  Lawrence  River),  respectively. 
Associated  with  each  vessel  is  a  list  of  attributes  which  carry  the  follow¬ 
ing  information: 

1.  Vessel  type  -  whether  saltwater,  dry  bulk  or  liquid  bulk 

2.  Physical  data 

(a)  capacity 

(b)  draft 

(c)  horsepower 

(d)  length 

(e)  unloading  rate  (for  self-unloaders) 


3 


This  is  why  vessels  are  characterized 


as  temporary  entitles. 
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3.  Dynamic  system  variables  such  as  current  location, 
destination  and  current  cargo. 

Recall  that  the  destination  and  current  cargo  attributes  are  determined 
within  the  port  function.  Other  dynamic  system  variables  such  as  current 
location  and  next  node  are  determined  and  continually  updated  by  the  move¬ 
ment  control  routine. 

Within  the  movement  control  routine,  the  selection  of  each  successive 
node  in  the  path  from  the  origin  to  destination  is  made  by  reference  to 
the  table  of  next  nodes.  The  identification  of  the  next  facility  to  be 
encountered  by  a  vessel  is  accomplished  through  the  use  of  the  facilities 
id  table.  However,  if  the  vessel  is  faced  with  a  parallel  routes  option, 
the  entry  in  the  table  of  next  nodes  is  a  pointer  to  the  parallel  facilities 
table  which  lists  the  alternatives  available.  A  separate  routine  is  then 
called  to  select  the  alternative  (route)  with  the  lower  expected  transit 
time . 

A  series  of  individual  routines,  referenced  appropriately  by  the  move¬ 
ment  control  routine,  governs  the  timing  of  the  vessel's  movement  through 
lakes,  reaches  and  locks.  The  diagram  in  Figure  3—1  illustrates  these  inter¬ 
actions.  The  lake  and  reach  routines  are  rather  simple.  Transit  times  for 
these  facilities  are  based  upon  an  average  speed;  in  the  case  of  the  lake, 
the  average  speed  is  adjusted  for  vessel  horsepower.  In  addition,  a  no¬ 
passing  rule  may  be  imposed  upon  any  reach. ^  Vessel  processing  in  the  lock 
and  port  routines,  by  comparison,  is  quite  complex  and  merits  separate 
discussions. 


^The  no-passing  rule  is  the  only  delay  constraint  currently  implemented  in 
the  reach  routines.  Other  delays  due  to  bridges,  one  lane  passage,  etc., 
are  not  explicitly  considered.  Due  to  the  modular  approach,  however,  it 
would  not  be  difficult  to  incorporate  these  contingencies. 
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Figure  3-1.  NETSIM  II  Program  Flow 


3.  Lock  Function 


The  lock  function  employs  one  main  arrive-at-lock  routine,  and  six 
event  routines.  The  arrive-at-lock  routine  is  initiated  by  the  movement 
control  routine  when  a  vessel  arrives  at  a  lock.  The  subsequent  operations 
provided  within  the  lock  function  are  schematically  represented  in  Figure 


The  arrive-at-lock  routine  can  perform  one  of  three  changes  in  a 
vessel's  status:  it  can  allow  the  vessel  to  (1)  enter  queue;  (2)  enter 
short  entry  position  just  outside  and  clear  of  the  entry  gate;  (3)  enter 
lock  chamber  directly.  A  myriad  of  lock  conditions  govern  the  final 
selection  of  a  particular  status  change  and  these  are  shown  in  Table  3-1. 

A  unique  feature  of  this  selection  process  is  the  service  look  ahead  capa¬ 
bility  which  allows  the  program  (or  in  the  real  world  context,  the  lock 
master)  to  scan  adjacent  reaches  for  imminent  lock  arrivals.  For  example, 
when  the  lock  is  idle  the  program  can  commit  the  lock,  recycling  if  neces¬ 
sary,  to  an  imminent  arrival  in  an  adjacent  reach  in  order  to  minimize  its 
delay.  When  imminent  arrivals  are  present  in  both  reaches  on  either  side 
of  the  lock,  the  program  determines  which  vessel  can  arrive  at  the  lock 
chamber  earlier,  taking  into  consideration  the  time  required  for  recycling. 


Once  a  vessel  is  accorded  its  appropriate  status  change,  its  progress 
through  the  lock  is  performed  through  the  event  routines  as  events  occur. 
This  is  perhaps  best  explained  by  way  of  an  example.  The  following  is  an 
illustration  of  some  normal  processing  that  might  be  carried  out  by  the 


lock  function. 


Clock  -  1249 
(Vessel  I 


Event 

Time 


Event 

Type 


1262  End  Cycle 

1251  Leave  Reach 


Queue  Short  Entry  Throat  Cycle  Cycle  Gates  Clear 
Position  Point 


TABLE  3-1.  Lock  Conditions  in  Arrive-at-Lock  Routine 


Vessel  Status 
Enters  queue 


enter  short  entry  position 


enter  chamber  directly 


Alternative  Conditions 

(1)  upstream  or  downstream  queue  (or 
both)  is  occupied 

(2)  the  lock  chamber  or  the  lock  throats 
contain  a  vessel  moving  toward 
vessel 

(3) *  far  reach  contains  a  vessel  moving 

toward  arrival  vessel  and  reach 
vessel  can  enter  lock  chamber 
earlier  than  the  arrival  vessel 

(1)  ]!ock  is  unoccupied  but  water  level 
is  not  correct 

(2)  lock  contains  a  vessel  moving  in 
same  direction,  lock  is  otherwise 
empty  but  water  level  is  not  correct 

(3) *  of  all  imminent  arrivals,  the  subject 

vessel  can  make  earliest  chamber 
entry,  but  water  level  is  not 
correct 

(1)  same  as  above  three  cases  but  water 
level  is  correct  or  will  be  correct 
at  chamber  entry  time. 


Asterisk  indicates  use  of  the  service  look  ahead  capability  whose 
explanation  is  given  in  text. 
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This  example  assumes  that  the  current  clock  time  is  1249.  For  the  sake  of 
simplicity,  the  lock  is  assumed  to  have  only  two  vessels  in  its  vicinity. 
Vessel  //I  is  in  the  lock  chamber  and  awaits  the  end  of  the  locking  cycle  at 
time  1262.  Vessel  #2  is  scheduled  to  leave  an  adjacent  reach  at  time  1251, 
and  is  assumed  to  be  traveling  in  the  same  direction  as  the  other  vessel. 

If  there  are  no  other  events  to  precede  it,  the  simulation  clock  is 
advanced  to  the  time  of  the  next  earliest  event,  leave  reach  at  time  1251. 
Vessel  it 2  is  now  at  the  lock  clear  point  and  the  arrive-at-lock  routine  is 
invoked  by  the  movement  control  routine.  Consistent  with  the  conditions  in 
Table  1,  the  vessel  performs  entry  into  the  short  entry  position,  its 
arrival  to  be  completed  at  time  1259.  At  that  time  the  lock  situation  is 
as  follows:'* 

Clock  »  1259 


Vessel 

Event 

Event 

it 

Time 

Type 

1 

1262 

End  Cycle 

Note  that  Vessel  it 2  no  longer  appears  in  the  above  illustration  as  each 
event  notice  is  destroyed  upon  its  execution.  The  clock  is  now  incremented 
to  time  1262.  The  end  cycle  event  routine  is  invoked  to  execute  this  event 
and  it  schedules  an  event  to  pass  through  gates  clear  poirt  say  at  time  1267. 

At  time  1267,  th*>  pass  through  gates  clear  point  event  routine  is 
called  to  execute  this  event.  This  routine  performs  two  activities.  First, 
it  schedules  Vessel  it  1  to  exit  the  lock  at  time  1280  through  the  transit 


Actually,  SIMSCRIPT  provides  an  event  notice  to  carry  information  pertinent 
to  a  particular  event  that  Is  to  occur.  The  illustrations  given  here  are 
for  the  sake  of  convenience  only. 
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throat  event.  Second,  it  scans  the  lock  vicinity  (queues,  throats, 
adjacent  reaches)  and  perceives  Vessel  It 2  at  short  entry  position.  It 
then  schedules  a  begin  cycle  event  to  take  place  at  current  clock  time 
so  that  the  lock  can  commence  to  recycle.  The  begin  cycle  event  routine 
schedules  an  end  cycle  at  time  1272.  The  lock  situation  is  now  follows. 


The  clock  is  now  advanced  to  time  1272  and  the  end  cycle  event  routine  is 
called  by  the  timing  routine.  The  function  of  the  end  cycle  event  routine 
is  different  in  this  instance  from  previously  because  the  lock  chamber  is 
empty.  The  routine  therefore  finds  the  vessel  in  short  entry  position  and 
schedules  it  to  enter  the  lock  at  time  1279  through  the  transit  throat  event. 
The  new  lock  situation  is  shown  below. 


Clock  -  1272 


At  time  1279  Vessel  It 2  enters  the  lock  and  the  lock  is  cycled.  The  sub¬ 
sequent  lock  exit  procedures  for  the  vessel  are  performed  in  a  manner 
similar  to  that  for  Vessel  #1.  The  latter,  of  course,  makes  its  lock 
departure  at  time  1280  and  supervision  over  its  passage  is  transferred 
back  to  the  movement  control  routine. 
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In  summary,  the  event  routines  in  the  lock  function  have  three 
major  functions:  (1)  execute  the  event  for  the  subject  vessel;  (2) 
examine  the  lock  situation  for  other  vessels  and  trigger  appropriate 
events;  and  (3)  print  relevant  statistics  for  the  event  log.  The  last 
function  is,  of  course,  a  mainstay  of  all  event  routines  in  NETSIM  II. 

It  Is  useful  to  point  out  that  the  locking  operation  is  always  carried 
out  incrementally  in  a  number  of  stages.  These  stages  are  the  lock  clear 
point  to  the  short  entry  position  (unless  vessel  enters  chamber  directly), 
the  chamber,  the  gates  clear  point  and  finally  the  lock  clear  point  on  the 
other  side.  A  snapshot  view  at  any  single  point  of  time  would  reveal  a 
locking  vessel  in  one  of  these  stages,  a  concept  found  useful  for  the  ETT 
channel  choice  mechanism  as  will  be  shown  in  a  later  section. 

The  queue  discipline  employed  in  NETSIM  II  is  the  SOQA  (Serve  Opposing 
Queues  Alternately)  Rule.  This  is  complemented  by  the  service  look  ahead 
capability  mentioned  earlier,  which  comes  into  play  when  the  queues  are 
empty.  Changing  the  queue  discipline  in  NETSIM  II  would  be  moderately 
difficult  as  changes  would  be  necessitated  in  every  routine  within  the  lock 
function  (but  not  anywhere  else). 

4.  Port  Function 

Besides  the  lock  function,  the  port  function  is  the  next  most  compli¬ 
cated  process  in  NETSIM  II.  The  complexity  arises  out  of  the  fact  that 
the  port  function  plays  a  major  role  within  NETSIM  II’ s  attempts  to  simulate 
the  GL-SLS  navigation  system's  vessel  scheduling  and  cargo  handling  trans¬ 
actions.  Although  vessel  processing  at  ports,  per  se,  is  rather  simply 
handled,  considerable  efforts  have  been  expended  to  inject  some  element  of 
realism  to  the  task  of  balancing  transport  supply  and  demand.  The  reader 
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therefore  is  urged  to  note  carefully  all  assumptions  and  levels  of  aggre¬ 
gation  so  he  may  make  his  own  judgement  as  to  the  model’s  validity.  It 
is  also  necessary  to  point  out  that  certain  phases  of  the  vessel  scheduling 
and  cargo  handling  procedures  have  been  made  external  input  into  NETSIM  II. 
For  example,  the  logic  for  generation  of  commodity  arrivals  and  itineraries 
for  saltwater  vessels  resides  in  NETSIM  II 's  support  programs  which  are 
presented  in  Part  3  of  this  report. 

The  port  function  has  three  primary  objectives: 

1.  The  port  routines  control  the  amount  of  time  a  vessel  spends 
in  port  and  provide  the  logic  whereby  ports  serve  as  the 
origins  and  destinations  for  vessels. 

2.  The  port  routines  also  provide  the  logic  for  the  selection 
of  cargo  to  be  loaded  onto  a  vessel  (if  any).  An  ancillary 
product  of  this  task,  in  the  case  of  local  bulk  carriers,  is 
the  creation  of  a  dynamic  scheduling  mechanism  since  the 
destinations  of  these  vessels  are  determined  by  the  destina¬ 
tions  of  their  cargoes. 

3.  The  port  function  also  contains  the  subprograms  for  processing 
NETSIM  II's  two  exogenous  events,  commodity  arrivals  and  vessel 
introductions.  Thus  each  port  contains  an  updated  inventory 
list  of  commodities,  vessels  and  port  equipment  classified  by 
type  and  status  (idle,  busy,  loading,  etc.)  during  the 
simulation. 

Each  of  these  functions  is  discussed  below. 

a.  Port  Turnaround  Time 

A  port  is  represented  as  having  a  number  of  berths  classified  into 
four  types:  general  cargo,  bulk  liquid,  grain  and  other  dry  bulk.  Time 
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in  port  is  the  sum  of  four  elements:  (1)  a  small  minimum  time  to  enter 
and  exit  the  port;  (2)  actual  loading  and  unloading  time,  which  is  deter¬ 
mined  by  the  tonnage  being  transferred  and  the  transfer  rate  for  the 
cargo-handling  equipment  at  a  berth  (or  for  the  vessel  if  it  is  a  self¬ 
unloader);  (3)  time  spent  in  queues  waiting  for  a  berth  or  for  cargo**  and 
(4)  a  random  factor  to  account  for  other  delays.^  This  fourth  element  is 
calculated  by  drawing  a  random  sample  from  an  exponential  distribution 
with  a  user  specified  mean  (and  variance). 

b.  Selection  of  Cargo 

The  heart  of  the  cargo  selection  mechanism  is  a  two-dimensional 
commodity  inventory  matrix  maintained  at  each  port.  This  matrix  is  a 
collection  of  updated  commodity  tonnages  by  type  and  destination.  A 
vessel’s  cargo  is  taken  from  the  matrix  cell  with  the  largest  available 
tonnage,  considering,  of  course,  only  those  cargoes  which  the  vessel  is 
capable  of  carrying.  Also,  a  vessel  of  length  greater  than  730  feet  cannot 
accept  a  cargo  which  would  require  it  to  pass  through  the  Welland  Canal. 

A  certain  minimum  amount  of  cargo  must  be  available  to  qualify  for  load¬ 
ing  onto  a  vessel.  If  no  minimum  load  is  available  at  the  port,  inquiry 
can  be  made  at  one  or  more  nearby  ports  to  determine  whether  a  suitable 
cargo  is  available  there.  If  so,  that  cargo  is  earmarked  for  the  particular 
vessel  and  the  vessel  is  dispatched  to  the  nearby  port  for  loading. 


^This  delay  time  is  not  explicitly  calculated  as  are  the  other 
elements,  since  delay  is  stochastically  determined  during  simulation. 

^For  example,  time  to  change  berths,  weather  delays,  etc. 
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One  aspect  of  the  bulk  cargo  selection  and  loading  algorithm 
which  may  seem  somewhat  strange  to  the  user  at  first  is  the  fact  that  a 
vessel  may  "load"  more  cargo  than  is  actually  available,  leaving  the 
inventory  level  at  the  port  temporarily  negative.  In  the  real  world 
system,  commodities  do  not  flow  uniformly  into  port  as  is  likely  to  be 
the  case  in  a  simulation.  Rather,  they  flow  irregularly,  and  often  the 
arrival  of  the  commodity  and  the  arrival  of  the  vessel  are  coordinated  so 
that  the  cargo  is  ready  for  loading  when  the  vessel  arrives.  Since  this 
coordination  mechanism  is  not  provided  in  NETSIM  II,  it  would  probably  be 
too  inflexible  to  restrict  the  vessel  to  the  quantity  of  cargo  that  happens 
to  be  available.  Rather,  if  cargo  is  available  in  a  user  specified  minimum 
amount,  the  vessel  is  allowed  to  load  to  its  capacity.  Suppose,  in  a  par¬ 
ticular  case,  a  minimum  qualifying  load  of  10,000  tons  of  coal  is  available, 
but  the  vessel  can  carry  15,000  tons.  Allowing  the  vessel  to  load  15,000 
tons  amounts  to  recognizing  the  fact  that  in  real  life  the  amount  of  coal 
shipped  overland  into  the  port  would  likely  have  been  adjusted  to  equal 
the  vessel's  capacity. 

Bulk  carriers  in  the  Great  Lakes-St.  Lawrence  Waterway  System  do,  in 
fact,  make  a  large  percentage  of  empty  backhauls.  In  order  to  reflect 
this  situation,  the  model  allows  for  specification  of  the  percentage  of 
empty  return  trips  by  port-of-origin  and  commodity.  During  a  simulation 
run,  then,  each  loaded  transit  may  or  may  not  be  followed  by  an  empty 
return  trip  according  to  the  appropriate  given  probability. 

In  addition  to  the  mechanism  just  mentioned,  there  are  two  situations 
that  can  arise  during  the  course  of  a  simulation  which  lead  to  empty  back¬ 
haul  trips.  First,  in  a  case  wherein  a  cargo  queue  (vessels  awaiting 
assignment  of  cargo)  is  larger  than  the  user  specified  limit  for  a  port, 
vessels  of  that  type  arriving  in  port  are  sent  back  to  their  origins  empty 


alter  being  unloaded.  This  is  to  prevent  further  buildup  of  the  already 
excessive  supply  of  vessels  of  a  particular  type.  Second,  is  the  case  in 
which  the  amount  of  cargo  awaiting  transit  at  a  port  has  built  up  beyond 
the  allowable  user-specified  limit  (in  terms  of  number  of  days'  influx). 
Then  any  vessel  which  is  capable  of  carrying  that  type  of  cargo  is  marked 
for  empty  backhaul  when  it  is  dispatched  from  port.  This  signals  its 
destination  port  to  return  it  empty.  Hence,  in  this  situation  of  under¬ 
supply  of  vessels,  the  port  assures,  at  least,  that  none  of  the  (local 
bulk)  vessels  currently  in  its  service  will  be  lost  to  other  routes. 

c.  Exogenous  Event  Processing 

The  port  function  contains  the  subprograms  for  processing  NETSIM  II 's 
two  exogenous  events,  commodity  arrivals  and  vessel  introductions. 

Vessel  introductions  are  handled  through  the  create  vessel  event 
routine  which  reads  data  for  the  following  vessel  attributes: 

length 

horsepower 

capacity 

unloading  rate  (for  self-unloaders) 
draft 

classification 

code  for  empty  backhaul 

cargo  tonnage 

cargo  type 

origin . 

In  addition,  the  routine  constructs  values  for  the  vessel's  dynamic 
system  variables  such  as  current  node,  next  node  and  destination.  Finally, 
the  routine  introduces  each  vessel  into  the  system  at  its  origin  port. 
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Commodity  arrivals  are  handled  through  the  commodity  arrival  event 
routine  which  reads  the  following  data  for  each  arrival  shipment: 

origin  port 
destination  port 
commodity  type 
commodity  tonnage. 

This  event  routine  next  updates  the  commodity  inventory  matrix  and  certain 
other  variables  used  during  the  internal  processing  within  port  routines. 

It  also  initiates  a  check  of  vessels  waiting  in  queues  for  cargo  to  see  if 
suitable  cargo  is  now  available  for  these  vessels. 

d.  Internal  Vessel  Processing  Within  Ports 

The  port  function  consists  of  five  routines,  one  endogenous  event 
routine  and  the  two  exogenous  event  routines  mentioned  above.  Their  names, 
functions  and  relationships  are  tabulated  in  Table  3-2. 

When  a  vessel  arrives  at  a  port,  the  enter  port  routine  checks  the 
vessel's  status  with  respect  to  its  cargo.  The  vessel  is  entered  into  a 
berth  (provided  one  is  available,  otherwise,  it  joins  a  berth  queue)  under 
three  circumstances: 

(1)  Vessel  is  loaded  and  enters  berth  for  unloading. 

(2)  Vessel  is  empty,  however,  a  cargo  is  marked  for  this 
vessel  at  this  port.  This  situation  is  the  end 
product  of  an  inquiry  of  nearby  ports  at  its  previous 
port  stop. 

(3)  Vessel  is  empty,  but  a  suitable  cargo  is  found  by  the 
search  for  cargo  routine. 
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TABLE  3-2.  Port  Function  Routines 


Type 

Name  of  Routine 

Function 

Calling 

Routine 

(Scheduling 
Routine  in 
case  of  event). 

Routine 

ENT. PORT 

Determines  vessel's  status 
(loading,  unloading,  final 
destination,  etc.),  checks 
port  equipment  usage  (avail¬ 
ability  of  berths,  etc.)  and 
references  appropriate 
routines. 

MOVEMENT  CONTROL 
EXT. BERTH 

CHK. CARGO. QUEUES 

Event 

EXT. BERTH 

Executes  vessel  exit  from 
berth,  updates  port  equip¬ 
ment  usage,  vessel  attri¬ 
butes  and  port  attributes. 

ENT. BERTH 

Routine 

ENT. BERTH 

Executes  vessel  entry  into 
berth,  updates  port  equip¬ 
ment  usage,  vessel  attri¬ 
butes  and  port  attributes 
and  schedules  an  exit  from 
berth  by  calculating  cargo 
transaction  time. 

ENT. PORT 

EXT. BERTH 

Routine 

CHK. CARGO. QUEUES 

Checks  to  see  if  suitable 
cargo  has  arrived  at  port 
for  vessels  waiting  in 
cargo  queues. 

COM. ARRIVAL 

Routine 

UPDATE. RATIOS 

Updates  port  routines' 
internal  variables. 

ENT. PORT 

Routine 

SRCH. FOR. CARGO 

Checks  cargo  inventories 
at  ports  to  select  suit¬ 
able  shipment  for  a 
vessel  awaiting  cargo. 

ENT. PORT 

CHK. CARGO. QUEUES 

Event 

COM. ARRIVAL 

Processes  commodity 
arrivals,  initiates  check 
of  cargo  queues. 

Timing  Routine 

Event 


CREAT. VESSEL 


Executes  vessel  intro¬ 
ductions. 


Timing  Routine 


^5^ 


The  above  three  cases  result  In  a  call  to  the  enter  berth  routine.  As 
shown  in  Table  3-2,  this  routine  executes  vessel  entry  into  berth,  updates 
port  equipment  usage,  vessel  attributes  and  port  attributes,  and  schedules 
an  exit  from  the  berth  at  an  appropriate  cargo  transaction  time  calculated 
in  the  manner  discussed  previously  under  subsection  (a)  titled  "Port 
Turnaround  Time." 

After  a  vessel  unloads  its  cargo,  a  search  is  again  made  to  find 
suitable  cargo  for  a  new  journey  unless  this  vessel  is  marked  for  an  empty 
backhaul  in  which  case  it  is  sent  back  to  its  origin  port.  For  a  vessel 
that  has  loaded  its  cargo,  the  program  determines  whether  this  vessel 
should  be  marked  for  an  empty  backhaul.  The  criteria  for  determining  when 
an  empty  backhaul  should  be  made  were  described  above.  Three  kinds  of 
user-supplied  constants  which  are  involved  in  this  mechanism  can  serve  as 
calibration  factors  for  the  model.  Those  factors  are  (1)  maximum  cargo 
queue  sizes,  (2)  maximum  cargo  inventory  accumulation  levels  and  (3)  the 
probability  that  an  empty  backhaul  will  occur  (in  the  case  where  a  vessel 
has  not  already  been  marked  for  empty  backhaul  based  on  cargo  queue  size 
or  cargo  inventory  level). 

Besides  the  three  just  mentioned,  there  are  many  additional  factors 
which  permit  the  user  considerable  flexibility  in  calibrating  the  model 
and  some  of  these  are  mentioned  below.  It  is  critical  to  point  out  the 
importance  of  this  aspect  of  the  simulation,  since  the  establishment  of  a 
realistic  simulation — a  normative  behavior— which  may  be  used  as  a  basis 
for  comparison  of  other  simulation  runs  is  seldom  achieved  easily  for  large 
systems.  More  often  than  not,  this  difficulty  is  predicated  on  the  desired 
levels  of  accuracy  for  simulation  data.  For  example,  the  data  needs  for 
NETSIM  II,  despite  the  levels  of  aggregation,  are  indeed  complex  and  will 
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require  conscientious  data  collection  efforts.  The  calibration  factors, 
then,  provide  the  user  with  some  flexibility  in  achieving  a  realistic 
simulation. 

The  calibration  factors  within  the  port  function  include: 

maximum  inventory  accumulation  levels 

probabilities  of  empty  backhaul 

minimum  cargo  levels 

vessel  loading  factor 

minimum  turnaround  time 

random  factor  for  turnaround  time 

number  of  nearby  ports 

maximum  cargo  queue  sizes. 

Other  variables  which  may  be  construed  as  calibration  factors  are  the  dis¬ 
tribution  used  to  generate  commodity  arrivals  and  the  parameters  used  to 
formulate  itineraries  for  saltwater  vessels.  These  variables  physically 

O 

exist  external  to  NETSIM  II,  however. 

Figure  3-3  (a)  and  (b)  is  a  simplified  representation  of  the  vessel 
handling  logic  (for  bulk  vessels  only)  in  ports.  These  flow  charts  are 
intended  to  give  the  reader  an  understanding  of  the  logic  flow  involved; 
they  do  not  reveal  in  which  subroutines  the  various  logic  segments  reside. 
Processing  for  saltwater  vessels  is  analogous  but  different  in  several 
respects  due  to  the  presence  of  pre-assigned  itineraries  and  to  the  nature 
of  the  cargo  selection  procedure. 

In  several  places  throughout  this  report,  reference  is  made  to  the 
vessel  attribute,  code  for  dedicated  cargo.  This  is  an  internal  code  which 


g 

The  lock  and  lake  routines  also  use  the  vessel  classification 
paramters  as  adjusting  factors  to  modify  vessel  processing  times. 
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is  used  in  the  port  routines  as  follows.  After  a  search  for  cargo  has 
been  carried  out  for  a  vessel,  the  cargo  selected,  if  any,  must  be 
"earmarked"  for  the  particular  vessel.  This  is  because  the  loading  may 
not  commence  immediately;  the  vessel  may  either  have  to  travel  to  a  nearby 
port  or  wait  in  a  berth  queue  first.  The  "earmarking"  consists  of  the 
following  steps: 

(1)  the  vessel's  cargo  tonnage  attribute  is  increased  by 
the  amount  of  cargo  to  be  loaded; 

(2)  the  commodity  inventory  matrix  in  the  port  is  decreased 
by  the  amount  of  cargo  to  be  loaded; 

(3)  the  vessel's  code  for  dedicated  cargo  (DED. CARGO)  is 
set  to  the  destination  port  number  of  the  cargo  to  be 
loaded ; 

(4)  the  vessel's  cargo  type  attribute  is  set  to  the  type 
code  for  the  cargo  to  be  loaded. 

Hence,  the  dedicated  cargo  code  is  an  indicator  to  keep  track  of  the 
destination  of  the  cargo  which  has  been  earmarked  for  a  vessel.  The  steps 
outlined  above  reveal  a  point  which  the  NETSIM  II  user  should  keep  in  mind 
if  it  ever  becomes  necessary  to  examine  an  event  log  in  detail.  That  is, 
that  a  vessel  which  appears  to  be  loaded  based  upon  the  cargo  tonnage 
attribute  (non-zero)  may  indeed  be  empty  and  en  route  to  pick  up  a  selected 
unit  of  cargo.  Both  the  cargo  tonnage  attribute  and  the  dedicated  cargo 
code  must  be  examined  to  determine  whether  a  vessel  is  loaded  or  empty. 

5.  Alternative  Channel  Choice  Mechanism 

Simulations  of  systems  containing  parallel  route  options  require  a 
procedure  whereby  vessels  can  be  assigned  to  a  particular  route  at  various 
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times  during  the  simulation.  NETSIM  II  handles  this  contingency  through 
the  experience  data  bank  (EDB)  concept.  A  vessel  confronted  with  a  choice 
between  two  or  more  parallel  routes  to  the  same  destination  selects  the 
route  with  the  lower  expected  transit  time.  In  order  to  establish  the 
criteria  for  estimating  such  expected  transit  times,  an  EDB  simulation  run 
is  made  in  which  parallel  route  selections  are  made  randomly  and  resulting 
transit  times  are  recorded  along  with  parameters  which  describe  the  state 
of  the  route  segment  of  interest.  Then,  based  on  these  simulation  "experience" 
results,  statistical  analysis  provides  the  relationships  between  the  usage 
parameters  for  each  parallel  segment  and  the  corresponding  expected  transit 
times.  These  relationships  or  ETT  functions  are  then  used  in  subsequent 
simulation  runs  for  alternative  route  selection.  In  the  context  of  the 
St.  Lawrence  Seaway  system,  the  Welland  Canal  and  the  proposed  Niagara  Canal 
constitute  such  an  alternative  parallel  route  structure. 

The  alternative  selector  routine  is  employed  in  NETSIM  II  to  perform 
the  channel  choice  decision.  When  a  vessel  is  confronted  with  parallel 
routes,  this  routine  calculates  current  values  for  the  usage  parameters 
and  utilizes  the  ETT  functions  to  calculate  the  route  with  the  lower 
expected  transit  time.  Any  route  which  physically  precludes  the  passage 
of  this  vessel  is  automatically  excluded  from  consideration  (for  example, 
lock  dimensions  may  preclude  certain  large  vessels).  NETSIM  II  employs  the 
following  usage  parameters  listed  by  entity: 

(1)  Vessels 
length 
draft 

(2)  Reaches 

number  of  vessels  in  reach,  i.e.,  reach  traffic 
length  of  reach 
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(3) 


Locks 


vessels  In  upstream  queue 
vessels  in  downstream  queue 

(4)  Route 

vessels  in  transit  on  route. 

Additional  parameters  could  be  easily  implemented  in  the  alternative 
selector  routine. 

6.  Monte  Carlo  Sampling 

NETSIM  II  requires  Monte  Carlo  sampling  at  various  locations  within  the 
program.  A  separate  routine  has  been  provided  within  NETSIM  II  to  centralize 
these  tasks  so  that  during  simulation,  whenever  a  random  time  is  needed,  the 
stochastic  time  calculations  routine  can  be  called  to  provide  this  element. 
This  routine  is  used,  for  example,  to  provide  the  time  elements  from  locking 
time  frequency  distributions,  reach  transit  time  distributions  and  lake 
transit  time  calculations. 

The  user  can  provide  a  maximum  of  ten  distributions  for  each  of  the 
five  locking  segments  (i.e.,  a  total  of  fifty  locking  time  distributions). 
Alternatively,  the  user  can  specify  the  use  of  a  theoretical  distribution 
from  among  eleven  statistical  functions  supplied  by  SIMSCRIPT.  These 
functions  are  listed  in  Table  3-3.  In  either  case,  the  five  locking  segments 
may  be  further  adjusted  at  user's  specification  to  represent  special  condi¬ 
tions.  The  long  entry,  for  example,  can  be  adjusted  to  reflect  both 
chamber  entry  from  a  stationary  position  at  queue  and  a  moving  entry  into 
chamber. 

After  sampling,  the  sampled  time  for  a  particular  locking  operation 
may  be  modified  according  to  vessel  attributes.  In  the  real  world  the  lock 
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TABLE  3-3.  SIMSCRIPT  Statistical  Functions 


Function _ 

BETA.  F 
BINOMIAL.  F 
ERLANG.  F 
EXPONENTIAL.  F 
GAMMA.  F 
LOGNORMAL.  F 
NORMAL.  F 
POISSON.  F 
RANDI.  F 
UNIFORM.  F 


NETSIM  II  Code 
1 
2 

3 

4 

5 

6 

7 

8 
9 

10 


WEIBULL.  F 


11 


entry  time  for  300  ft  vessel  may  be  considerably  less  than  that  for  a 
730  ft  vessel;  the  program  allows  the  user  to  state  explicitly  the  effect 
of  vessel  size  on  each  of  the  locking  operations. 

Each  reach  requires  two  transit  time  distributions  in  NETSIM  II,  one 
for  each  direction  of  travel.  They  may  again  be  either  empirical  or 
theoretical. 

Transit  through  lakes  is  accomplished  by  reference  to  an  intralake 
travel  table  which  lists  for  each  lake  the  average  transit  time  between 
any  two  nodes  on  the  lake.  This  average  value  is  then  adjusted  by  user 
supplied  factors  according  to  a  vessel's  horsepower.  Current  implementa¬ 
tion  in  NETSIM  II  distinguishes  vessels  by  the  following  horsepower 
categories: 

_ Horsepower _ 

Category  Lower  Bound  Upper  Bound 


1 

2 

3 

4 

5 


0 

2500 

2501 

4000 

4001 

5000 

5001 

<n>00 

8000 

_ 

Category  3  vessels,  i.e.,  vessels  with  horsepower  between  4001  and  5000, 
serve  as  the  average  for  the  purposes  of  calculating  lake  transit  times. 
Thus,  the  average  times  supplied  in  the  intralake  travel  table  are  averages 
for  category  3  vessels.  The  user  must  supply  adjusting  factors  for  cate¬ 
gories  1,  2,  4  and  5  differentiated  with  respect  to  category  3.  The  average 

value  is  then  adjusted  either  upward  or  downward  corresponding  to  whether 

9 

the  horsepower  is  higher  or  lower  than  the  average. 


9 

The  horsepower  categories  may  be  easily  modified  within  NETSIM  II.  The 
current  categories  were  formulated  based  on  the  availability  of  some 
crude  data. 
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7.  Representation  of  the  Welland  Canal 

Representation  of  the  Welland  Canal  as  a  collection  of  locks  and 
reaches  in  NETSIM  II  presents  a  grave  risk  in  that  it  ignores  the  effects 
of  the  rather  sophisticated  traffic  control  procedures  [7,  8]  governing 
vessel  movements  in  the  Canal.  An  interim  solution  to  this  problem  consists 
of  an  alternative  representation  of  the  Canal  as  a  single  unique  service 
facility. 

This  service  facility  is  a  simple  waiting  line  model,  mathematically 
categorized  as  M/G/l.  The  parameters  of  this  model  are  an  average  service 
rate  and  the  variance  of  the  service  distribution.  These  parameters  were 
empirically  determined  through  a  statistical  analysis  of  the  Vessel  Transit 
Analysis  daily  reports  [9]  for  the  months  of  June  and  August  1971. 

As  vessels  arrive  at  the  Welland  Canal,  the  model  seeks  to  predict 
their  average  delays  through  appropriate  formulas  in  queuing  theory.  Total 
transit  time  through  the  Canal  is  then  defined  as  the  sum  of  this  delay  and 
the  time  for  actual  transit. 

It  should  be  fairly  clear  that  the  result  of  this  approach  is  a  gross 
approximation  of  the  average  vessel  movement  time  through  the  Canal  and 
not  an  exact  or  detailed  representation  of  the  Canal  per  se.  Where  feasible, 
alternative  solutions  such  as  dividing  the  system  into  subsystems  or  employ¬ 
ing  other  analytical  models  should  be  diligently  explored. 


CHAPTER  4.  OUTPUT 


The  primary  NETSIM  II  output  is  an  event  log  which  is  a  description 
of  all  events  that  occurred  during  the  simulation.  Each  event  description 
lists  the  time  of  occurrence;  vessel  identification;  vessel  attributes  such 
as  length,  current  node,  next  node,  cargo  tonnage,  commodity  type  and  clas¬ 
sification;  facility  identification  and  an  event  code  which  specifies  the 
nature  of  the  event.  Normally,  the  user  will  wish  to  store  this  event  log 
on  an  auxiliary  unit  such  as  a  tape  file  so  that  it  can  be  conveniently  input 
to  PROSIM,  the  statistical  report  generator. 

NETSIM  II  provides  a  different  form  of  output  for  an  EDB  run.  The  EDB 
output  lists  the  transit  times  through  each  rouce,  along  with  a  snapshot 
view  of  the  traffic  conditions  on  the  route  when  a  vessel  arrived  at  the 
channel  choice  point  in  the  system.  Thus,  the  actual  transit  time  through 
a  route  may  be  statistically  related  to  these  usage  parameters — system 
conditions — to  generate  ETT  functions. 

In  addition  to  the  event  log,  NETSIM  II  also  prints  out  a  running 
account  of  commodity  inventory  levels  in  ports  during  the  simulation.  This 
report  is  generated  by  the  commodity  arrival  event  routine,  so  that  updated 
totals  are  printed  just  prior  to  arrival  of  commodities  into  port.  In  the 
report,  commodities  are  grouped  into  3  categories  according  to  the  cargo 
carrying  capabilities  of  the  three  classifications  of  vessels:  (1)  general 
cargo,  (2)  liquid  bulk  and  (3)  dry  bulk  (including  grain).  Inventories  of 
each  type  of  commodity  in  each  port  are  reported  in  two  different  sets  of 
units,  first,  hundreds  of  tons  and,  second,  number  of  days'  influx.  This 
second  statistic  is  the  inventory  level  that  is  used  in  determining  whether 
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to  mark  a  departing  loaded  vessel  for  empty  backhaul  (as  described  pre¬ 
viously).  A  more  detailed  description  of  the  inventory  level  report  as 
well  as  of  the  event  log  is  given  in  Appendix  A. 


CHAPTER  5.  PROGRAM  TESTS 


Having  labored  through  the  program  description  so  far,  the  reader 
may  wonder,  "How  realistic  is  it?  Dees  it  yield  valid  results?"  Since 
the  program  only  approximates  reality  and  since  it  contains  many  stochastic 
elements,  a  number  of  program  tests  are  necessary  to  assure  its  validity 
and  reliability.  It  is  the  purpose  of  this  chapter  to  describe  the  nature 
of  the  tests  that  have  been  conducted  on  NETSIM  II. 

A.  VALIDATION 

The  validity  of  a  simulation  is  a  measure  of  the  extent  to  which  it 
satisfies  its  design  objectives.  In  the  case  of  the  NETSIM  II-PROSIM  model, 
the  design  objective  was  the  development  of  a  model  with  capabilities  for 
comprehensive  GL-SLS  system  simulations.  Thus,  assurance  of  validity 
requires  the  following: 

(a)  The  theoretical  structure  of  the  model  including  all  the 
assumptions  must  appear  reasonable  in  relation  to  the 
real  world  phenomenon  being  simulated. 

(b)  The  internal  programming  logic  must  be  shown  to  be  correct. 

(c)  The  model  must  have  the  capability  for  specified  applications. 

Much  of  the  theoretical  consideration  in  NETSIM  II,  particularly  that 
concerned  with  locking  operations  and  to  a  lesser  extent  the  lake,  reach 
and  vessel  movement  control  operations,  are  derived  from  an  extension  of 
previous  work.  The  port  function  is  an  exception  to  this,  and  during  the 
course  of  its  development  a  considerable  amount  of  time  was  expended  on 
discussions  with  Great  Lakes  shippers,  carriers,  shipping  agents  and 


government  agencies  to  ensure  the  incorporation  of  the  major  concepts 
and  principles  underlying  GL-SLS  navigation.  Attempts  were  made  to 
minimize  the  twin  problems  of  including  too  much  detail  and/or  excluding 
major  operational  concepts  by  limiting  the  scope  of  the  model  to  its  design 
objectives  and  by  the  use  of  calibration  and  adjusting  factors.  The  latter 
will  be  considered  more  fully  in  the  next  section. 

Program  tests  on  the  NETSIN  II  program  fall  into  two  categories: 

(1)  testing  of  each  individual  component  in  the  program 
to  insure  that  it  is  internally  correct  in  terms  of 
both  modeling  logic  and  the  programming  statements; 

(2)  hooking  the  individual  components  together  and 
testing  the  entire  program. 

While  the  former  facilitated  debugging  and  ease  of  interpretation,  it  is  the 
latter  that  is  of  the  ultimate  interest  since  assurance  of  each  individual 
component  when  considered  in  isolation  does  not  necessarily  imply  the 
adequacy  of  the  entire  program.  Tests  described  below  are  of  the  second 
type. 

The  bulk  of  the  testing  of  the  NETSIM  II  program  was  carried  out  on  a 
hypothetical  navigation  system  network.  The  hypothetical  network  is  very 
similar  to  the  GL-SLS,  but  with  a  greatly  reduced  number  of  ports,  locks, 
reaches,  vessels  and  commodities  (for  one  form  of  this  network,  see 
Appendix  B) . 

The  bulk  of  the  analysis  consisted  of  detailed  examinations  of  the 
event  log  output  generated  by  the  program.  Using  the  small  network  as 
opposed  to  a  larger  one  offered  a  distinct  advantage  here  since  the  tested 
network,  simulated  typically  for  ten  or  twenty-day  periods,  exhibited  most 
of  the  situations  arising  in  larger  and  longer  simulations  and  yet  was 
easier  to  interpret  and  analyze. 


-50- 


The  event  log  analysis  took  the  following  four  forms. 

(1)  Examination  of  the  event  log  in  its  natural  form,  that  is, 
in  the  chronological  order  of  events.  A  partial  listing 
of  the  event  log  is  shown  in  Table  5-1  accompanied  by  an 
interpretation.  The  focus  of  this  type  of  an  examination 
was  on  the  vessel  handling  and  vessel  movement  aspects  of 
the  simulation  program  so  as  to  assure  proper  interplay 
among  the  program  routines. 

(2)  Examination  of  the  event  log  sorted  first  by  vessel  and  then 
by  time.  This  allowed  an  analysis  of  the  movements  of  each 
individual  vessel  in  the  system.  It  thus  provided  systematic 
information  on  the  times  spent  at  various  points  in  the 
system  including  delay,  processing  and  transit  times  and 
generated  the  data  needed  to  calculate  fleet  inventories 

at  ports,  port-to-port  routes  and  other  locations  in  the 
system. 

(3)  Examination  of  the  event  log  sorted  first  by  facility  and 
then  by  time.  This  simple  arrangement  facilitated  analysis 
of  each  facility  usage  as  can  be  readily  seen  in  Table  5-2 
which  gives  a  partial  listing  for  a  lock.  With  this  tool, 
each  event  occurrence  could  be  examined  and  related  to  the 
modeling  logic. 

(4)  Analysis  of  the  output  tables  generated  by  PROSIM:  These 
tables  contain  statistical  summaries  of  the  event  log  sorted 
by  vessel,  facility,  event  and  time. 
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TABLE  5-1.  Partial  Listing  of  the  NETSIM  II  Event  Log 
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Program  tests  of  the  forms  indicated  above  confirmed  the  general 
workability  of  the  simulation  program.  Also,  a  run  was  made  on  a  system 
very  nearly  representing  the  GL-SLS  in  order  to  demonstrate  the  feasibility 
of  simulating  a  system  of  that  magnitude  (for  a  brief  description  of  this 
simulation,  see  the  accompanying  Summary  Report  [10]  ). 

B.  CALIBRATION 

The  object  of  the  calibration  process  is  to  determine  the  degree  of 
error  that  exists  within  the  model  and  establish  a  procedure  for  dealing 
with  it.  During  the  course  of  program  testing,  need  for  several  calibration 
and  adjustment  factors  became  evident.  This  need  arose  in  the  following 
areas : 

1.  Port  Turnaround  Time 

The  deterministic  components  of  port  turnaround  time  are  a  minimum  time 
to  enter  and  exit  a  port,  the  actual  loading  and  unloading  time  as  determined 
by  the  tonnage  being  transferred  and  the  transfer  rate  for  the  cargo-handling 
equipment  at  a  berth  (or  for  the  vessel  if  it  is  a  self-unloader) ,  and  the 
time  spent  in  queues  waiting  for  a  berth  or  for  cargo.  In  addition  to  these, 
a  stochastic  component  was  deemed  necessary  to  account  for  other  delays  such 
as  time  to  change  berths  and  weather  delays. 

2.  Oversupply  of  Vessels  at  Ports 

Oversupply  of  vessels  at  ports  may  be  manifested  in  a  large  number  of 

vessels  waiting  in  queues  for  cargo  at  the  expense  of  an  undersupply  of 

vessels  at  other  locations  in  the  system.  To  correct  this  situation,  an 
automatic  limiting  factor  was  implemented  so  that  when  the  number  of  vessels 
in  a  port  waiting  for  cargo  exceeds  this  limit,  other  vessels  will  be  sent 

back  to  their  ports  of  origin  empty  rather  than  being  allowed  to  remain  and 

wait  for  cargo. 
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3.  Undersupply  of  Vessels  at  Ports 

Undersupply  of  vessels  may  result  in  an  abnormally  high  cargo 
inventory  at  a  port.  To  correct  this  situation,  another  limiting  factor 
was  incorporated  so  that  when  a  commodity  awaiting  transit  accumulates  beyond 
this  limit  in  a  port,  vessels  departing  loaded  will  be  marked  for  empty 
backhaul.  This  is  to  ensure  that  they  will  be  returned  to  this  port — where 
they  are  sorely  needed — rather  than  being  assigned  to  some  other  movement. 

This  arrangement  may  not  be  completely  satisfactory,  however,  since  a 
port  may  have  a  "small  enough"  transaction  of  a  particular  commodity  that 
the  inventory  may  not  reach  the  limiting  factor  for  a  considerable  period 
of  time,  yet  it  may  be  in  dire  need  of  vessels.  On  the  other  side  of  the 
coin,  this  situation  may  result  in  "captive"  vessels  which  may  not  have  a 
suitable  cargo  of  sufficient  quantity  to  transport  and  may  therefore  wait 
in  the  cargo  queue  for  a  long  period  of  time.  To  deal  with  these  problems, 
a  set  of  "nearby"  ports  can  be  specified  for  each  port  so  that  when  a 
vessel  cannot  find  a  suitable  cargo  in  its  current  port,  it  will  search  for 
cargo  in  "nearby"  ports. 

4.  Empty  Backhauls 

Bulk  carriers  in  the  GL-SLS  system  do  engage  in  a  large  percentage  of 
empty  backhauls.  In  order  to  reflect  this  situation,  the  percentage  of 
empty  return  trips  is  specified  for  each  port-of-origin  and  commodity. 

5.  Imbalance  Between  Commodities  and  Vessels 

If  there  is  a  systematic  imbalance  between  the  amount  of  cargo  to  be 
transported  and  the  transport  equipment  units  available,  then  the  number 
and  sizes  of  vessels  in  the  fleet  and  the  average  vessel  loading  factor  may 
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be  used  to  arrive  at  an  equilibrium.  This  last  factor  determines  the 
average  vessel  cargo  tonnage  as  a  fraction  of  the  vessel's  stated 
capacity. 

In  addition  to  the  specific  factors  stated  above,  a  number  of  adjust¬ 
ment  factors  based  on  differences  in  vessel  attributes  are  used  to  adjust 
average  vessel  processing  and  transit  times.  For  example,  the  transit  time 
through  a  lake  computed  from  the  intralake  travel  table  is  an  average  time 
for  a  vessel  of  4,001-5,000  horsepower.  This  time  is  adjusted  upward  or 
downward  depending  on  the  actual  vessel  horsepower  (the  exact  specification 
of  these  adjusting  factors  is  given  in  Appendix  A,  the  NETSIM  II  Users' 
Manual) . 

In  conclusion,  a  number  of  calibration  factors  have  been  implemented 
to  reduce  the  error  that  exists  within  the  model.  Stable  values  for  these 
factors  have  not  been  determined,  however,  since  an  accurate  data  base  for 
such  an  endeavor  (on  the  GL-SLS  system)  was  not  available  at  the  time. 
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APPENDIX  A 

NETSIM  II  USER  MANUAL 


J 


A.  INTRODUCTION 


This  manual  provides  the  information  needed  to  prepare  the  input  data 
for  and  interpret  the  output  of  the  NETSIM  II  portion  of  the  simulation 
package.  It  is  assumed  that  the  reader  has  a  thorough  understanding  of 
Chapters  1  and  2  of  this  volume,  and  is  familiar  with  the  contents  of 
Chapters  3  and  4.  Attention  here  is  focused  on  input/output  formats  rather 
than  on  system  or  programming  logic.*  However,  a  working  knowledge  of  the 
program  logic  flow  will  be  useful  in  resolving  many  of  the  problems 
encountered  in  developing  the  input  data  files.  For  this,  the  reader  is 
referred  to  Chapter  3. 

In  addition  to  familiarization  with  Part  I  of  this  volume,  the  user 
is  urged  to  consult  references  [11]  and  [12]  dealing  with  the  SIMSCRIPT 
language . 


B.  NUMBERING  CONVENTION  IN  NETSIM  II 

The  numbering  convention  in  NETSIM  II  consists  of  a  few  restrictions 
which  have  been  adopted  for  two  reasons.  First  of  all,  some  restrictions 
are  absolutely  vital  from  the  viewpoint  of  program  efficiency.  NETSIM  II 
takes  heavy  advantage  of  SIMSCRIPT' s  packing  capabilities — that  is,  the 
storing  of  multiple  data  values  in  a  computer  word.  This  also  implies, 
however,  that  the  packed  values  must  be  much  smaller  in  magnitude  than  when 
they  are  not  packed.  An  example  of  this  restriction  involves  the  vessel 
attribues,  length,  horsepower  and  tonnage.  Due  to  packing,  length  must  be 
expressed  in  tens  of  feet,  horsepower  in  hundreds  and  tonnage  in  hundreds 


of  tons. 


The  second  reason  for  adopting  the  numbering  convention  is  that  it 
facilitates  programming  and  error  detection.  Data  validity  checks  can  be 
built  into  the  program  to  a  greater  extent  and  errors  can  be  pinpointed 


more  easily.  The  numbering  convention  also  reduces  the  physical  size  of 
the  program  and  makes  it  easier  for  the  user  to  interpret  through  its  basic 
structure. 

The  number  conventions  consist  of  the  following: 

1.  Ports,  locks,  reaches  and  lakes  must  be  numbered  sequentially  in  order. 

2.  Ports  and  other  non-port  nodes  must  be  numbered  sequentially  in  order. 
For  example,  consider  a  system  with  8  ports,  3  locks,  7  reaches,  5  lakes  and 
12  nodes.  Ports  must  be  numbered  1  through  8,  locks  9  through  11,  reaches 
12  through  18,  lakes  19  through  23  and  non-port  nodes  9  through  12  (there 
are  8  port-nodes  and  4  non-port  nodes).  Note  that  locks  and  non-port  nodes 
are  numbered  sequentially  after  ports.  All  ports  above  the  Welland  Canal 
should  have  numbers  lower  than  those  below  Welland.  The  "Atlantic  Port" 
should  have  the  highest  number.  A  good  guide  rule  is  to  number  ports 
sequentially  from  "upstream"  to  "downstream." 

3.  Vessel  classifications  must  be  numbered  as  follows: 

1  *  saltwater  vessel 

2  *  liquid  bulk  vessels 

3  ■  dry  bulk  vessels. 

4.  Berth  types  at  ports  must  be  classified  as  follows: 

1  ■  general  cargo  berths 

2  ■  dry  bulk  (excluding  grain)  berths 

3  “  grain  berths 

4  ■  liquid  bulk  berths. 
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5.  The  only  restrictions  on  the  commodity  numbering  system  are  that 
general  cargo  must  be  the  last  commodity  type  and  that  all  dry  bulk 
commodities  including  grain  must  be  numbered  sequentially  as  a  group. 
Thus,  if  there  are  8  commodities,  the  following  numbering  system  is 
acceptable. 

Commodity  Type  Description  Special  Codes  Item 


1 

coal 

1 

DRY.LO 

A19 

2 

sand 

3 

grain 

dry 

GRN. INDEX 

A18 

4 

stone 

> 

bulk 

5 

iron 

6 

cement 

DRY. HI 

A20 

7 

liquid  bulk 

LIQ. INDEX 

A17 

8 

general 

cargo 

GEN. INDEX 

A16 

Note:  the  last  two  columns  indicate  special  codes,  and  their  sequential 
item  numbers  as  they  appear  in  the  next  section  under  input  formats. 

6.  A  system  containing  parallel  routes  requires  an  identification  number 
for  each  of  these  routes.  This  number  must  be  a  four  digit  code. 

C.  INPUT  DATA  FORMATS 

A  NETSIM  II  data  deck  consists  of  the  five  classes  of  data  described 
in  Chapter  2.  Some  of  these  data  are  in  fixed  format  and  others  can  be 
input  in  free-form.  For  the  latter,  there  are  two  governing  restrictions. 
First,  each  datum  must  be  separated  from  its  adjoining  data  by  at  least  one 
blank.  Second,  a  datum  must  not  be  continued  from  one  card  to  the  next. 
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Data  may  be  punched  as  either  real  or  integer.  The  important  thing  to 
remember  about  the  free-form  concept  is  that  the  program  reads  free-form 
input  as  a  continuous  stream  of  values.  Successive  numerical  values  are 
read  and  assigned  to  corresponding  variables  in  the  read  command.  The 
location  of  a  particular  datum  on  a  card  is  not  considered,  as  long  as  it 
is  properly  positioned  relative  to  other  data.  Unless  otherwise  indicated, 
all  data  below  can  be  input  in  free-form. 

The  card  format  descriptions  below  are  preceded  by  an  item  number, 
consisting  of  a  letter  and  a  number.  The  letter  refers  to  the  correspond¬ 
ing  section  of  Chapter  2  of  this  volume,  and  the  numbers  are  sequential. 
These  item  numbers  are  relevant  only  to  this  manual,  and  must  not  appear 
on  the  data  cards. 

Some  simulation  input  data  are  not  required  for  an  EDB  run.  Data 
cards  that  should  be  deleted  from  an  EDB  input  deck  consist  of  the  items 
for  ETT  functions  as  indicated  in  the  text  below. 

Card  Format  Specifications 

Item 

Number  Contents 

A1  SEASON. LENGTH 

This  is  the  total  simulation  time  including 
any  warm-up  time  needed  to  achieve  steady 
state. 

A2  EDB. CODE 

This  code  is  set  to  1  for  an  EDB  run,  0 
otherwise. 

A3  LOOK. AHEAD. CODE 

This  code  is  set  to  1  to  use  the  service 
look  ahead  feature,  0  otherwise. 
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Item 

Number 

A4 


A5 


A6 


A7 


A8 


A9 


A10 


All 


A12 


Contents 

PARA. CODE 

This  code  is  set  to  1  if  the  system 
contains  one  or  more  parallel  route 
options,  0  otherwise. 

TAPE. DRIVE 

This  field  provides  the  output  unit 
number  for  the  NETSIM  II  event  log  output. 
This  number  must  agree  with  the  data  set 
reference  number  (DSRN)  given  in  the  Data 
Definition  card  (DD  card  for  IBM  OS/360  JCL) . 
HI. PORT 

Identification  number  of  the  highest 
numbered  port. 

N.PORT 

Number  of  ports. 

HI. LOCK 

Identification  number  of  the  highest 
numbered  lock. 

N. LOCK 

Number  of  locks. 

HI. REACH 

Identification  number  of  the  highest  reach. 

N. REACH 

Number  of  reaches. 

HI. LAKE 

Identification  number  of  the  highest  lake* 


Item 

Number  Contents 

A13  N.LAKE 

Number  of  lakes. 

A14  SWITCH. FOR. WELLAND 

This  code  is  1  if  NETSIM  II's  representation 
of  the  Welland  Canal  is  to  be  used,  0 
otherwise. 

A15  NO. OF. NODES 

Number  of  nodes  in  the  system. 

A16  GEN. INDEX 

This  is  the  code  representing  general  cargo. 

A17  LIQ. INDEX 

This  code  represents  liquid  bulk  cargo . 

A18  GRN. INDEX 

This  code  represents  grain  cargo . 

A19  DRY.LO 

This  code  represents  the  lowest  numbered 
dry  bulk  cargo  (including  grain)  . 

A20  DRY. HI 

This  code  represents  the  highest  numbered 
dry  bulk  cargo  (including  grain)  . 

A21  ATLANTIC. PORT 

Identification  number  of  the  port  located 
at  the  eastern  end  of  the  simulation  system. 
This  port  serves  as  the  entry  and  exit  point 
for  saltwater  traffic  (should  be  the  same  as 


Item  A6  in  most  cases). 


Item 

Number  Contents 

A22  STREAM 

Index  number  representing  SIMSCRIPT-provided 
random  number  streams.  This  number  must 
have  a  value  between  1  and  10.  This  index 
is  used  for  random  sampling  from  probability 
distributions  for  saltwater  vessels'  cargo 
selection. 

A23  STREAM1 

Index  number  as  above  and  used  to  sample 
from  probability  distributions  for  empty 
backhaul. 

A24  STREAM2 

Index  number  as  above  and  used  for  the 
calculation  of  cargo  transaction  time 
in  a  berth. 

A25  G.C. SWITCH 

The  general  cargo  switch  can  take  on  a 
value  of  either  0  or  1.  If  its  value  is  0, 
a  saltwater  vessel  is  permitted  to  unload 
and  load  its  cargo  as  a  sequential  operation 
in  the  same  berth.  Otherwise,  if  the  value 
is  1,  the  vessel  must  relinquish  its  berth 
after  an  unloading  process  to  another  vessel 
awaiting  this  berth. 
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Item 

Number  Contents 

A26  ERIE. EAST 

Identification  number  of  the  highest 
numbered  port  west  of  the  Welland  Canal. 

A27  DR. MAX 

The  maximum  desired  number  of  days' 
commodity  accumulation  for  dry  bulk  cargo 
at  ports.  When  this  number  is  exceeded 
at  any  port,  dry  bulk  vessels  leaving  port 
loaded  will  be  marked  for  empty  backhaul. 

A28  LR.MAX 

As  above  for  liquid  bulk  cargo. 

A29  NUM.COMMOD 

Number  of  commodities.  There  is  no  limit 
on  this  number  in  NETSIM  II. 

A30  COMM. DEVICE 

Input  unit  with  the  commodity  arrival 
event  data. 

A31  SHIP. DEVICE 

Input  unit  with  the  vessel  introduction 
event  data. 

A32  1. CLASS 

Vessel  length  upperbound  for  Class  1,  in 
tens  of  feet. 

A33  2. CLASS 

Vessel  length  upperbound  for  Class  2,  in 
tens  of  feet.  Note  that  vessels  of  length 
less  than  1. CLASS  are  said  to  be  in  Class  1 
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Item 

Number 


A34 


A35 


A36 


A37 


A38 


Contents 

vessels  of  length  between  1. CLASS  and 
2. CLASS  In  Class  2  and  vessels  of  length 
over  2. CLASS  In  Class  3. 

IT. DEVICE 

Input  unit  containing  itineraries  for 
saltwater  vessels. 

RAT. UNIT 

Output  unit  for  printing  commodity 
inventories  at  ports. 

LK.2500HP .OR.LESS. ADJ 
Adjusting  factor  for  vessels  of  2500 
horsepower  or  less,  expressed  in  percentage. 
This  factor  is  used  to  modify  an  average 
lake  transit  time  obtained  from  the  intra¬ 
lake  travel  table.  For  example,  an  entry 
of  *108.5'  would  indicate  that  a  vessel 
with  2500  horsepower  or  less  requires  8.5 
percent  longer  than  the  average  figure  in 
the  table. 

LK. 4000HP . OR . LESS . ADJ 

Adjusting  factor  for  vessels  of  horsepower 
between  2501  and  4000  inclusive,  expressed 
in  percentage. 

LK .  5000HP . OR . GRT . ADJ 

Adjusting  factor  for  vessels  of  horsepower 
between  5001  and  8000  inclusive,  expressed 
in  percentage. 
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Item 

Number  Contents 

A39  LK . 8000HP . OR. GRT . ADJ 

Adjusting  factor  for  vessels  of  horsepower 
greater  than  8000  expressed  in  percentage. 

B1  VSL.LDG. FACTOR 

Vessel  loading  factor  expressed  as  a  decimal 
fraction.  A  value  of  1.0  indicates  that  a 
vessel  would,  if  suitable  cargo  was  available, 
load  fully  up  to  its  capacity. 

B2  MIN. CARG(l)  ,  MIN.CARG(2)  ,  MIN.CARG(3) 

A  vector  containing  the  minimum  cargo  levels 
(for  loading)  for  general,  dry  bulk  and  liquid 
bulk  cargoes,  respectively  (hundreds  of  tons). 

Cargoes  in  smaller  amounts  do  not  qualify  for 
loading. 

B3  BER.CONV (1)  ,  BER.C0NV(2)  .  BER. CONV (NUM.C0MM0D) 

A  vector  containing  the  berth  conversions  for  each 
commodity.  For  a  system  with  n  commodities,  there 
are  n  elements  in  this  vector.  To  illustrate  its 
use,  a  value  of  1  for  BER.C0NV(3)  indicates  that 
commodity  type  3  must  be  processed  (loaded  or 
unloaded)  in  berth  type  1.  There  are  four  berth 
types  in  NETSIM  II  (correspondingly,  the  elements 
of  this  vector  may  take  on  only  four  values:  1, 

2,  3  or  4): 

1  ■  general  cargo  berth;  2  «  dry  bulk  berth; 

3  ■  grain  berth;  4  *  liquid  bulk  berth. 
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Item 

Number 


Contents 


Items  B4  through  Bll  in  entirety  must  be 
repeated  for  each  port  until  all  the  ports 
are  exhausted. 


B4  The  following  are  in  10-column  fields,  right 

justified  (2  I  10,  3  D(10,0),  2  I  10) 

cc  1-10  port  identification  number 

11-20  lower  bound  on  port  turnaround  time,  minutes 
21-30  dry  bulk  cargo  influx  rate,  hundreds 
of  tons  per  day 

31-40  liquid  bulk  cargo  influx  rate,  hundreds 
of  tons  per  day 

41-50  general  cargo  influx  rate,  hundreds 
of  tons  per  day 
51-60  port  depth,  feet 
61-70  number  of  nearby  ports 

B5  POR . NUM (NRBY . PORT ) 

A  vector  containing  the  identification  numbers 
for  each  nearby  port.  The  numbers  are  given  in 
free  form. 

B6  The  following  are  in  10-column  fields ,  right 

justified.  The  first  element  is  integer  and 

the  next  four  are  real  (I  10,  4  D(10,0)  ). 

cc  1-10  port  identification  number 

11-20  general  cargo  unloading  rate, 
hundreds  of  tons/minute 
21-30  dry  bulk  cargo  unloading  rate, 
hundreds  of  tons/minute 
31-40  grain  unloading  rate,  hundreds  of 
tons /minute 

41-50  liquid  bulk  cargo  unloading  rate, 
hundreds  of  tons /minute 

B7  The  following  are  in  10-column  fields,  right 

justified.  The  first  element  is  integer  and 
the  next  four  are  real  (I  10,  4  D(10,0)  ). 
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Item 

Number 


B8 


B9 


BIO 


Contents 


cc 


1-10  port  identification  number 
11-20  general  cargo  loading  rate,  hundreds 
of  tons /minute 

21-30  dry  bulk  cargo  loading  rate, 
hundreds  of  tons /minute 
31-40  grain  loading  rate,  hundreds  of 
tons/minute 

41-50  liquid  bulk  cargo  loading  rate, 
hundreds  of  tons/minute 


The  following  are  in  10-column  fields,  right 
justified.  The  first  element  is  integer  and 
the  next  four  are  real  (I  10,  4  D(10,0)  ). 


cc 


1-10  port  identification  number 
11-20  random  factor  for  general  cargo 
vessels'  port  turnaround  time 
21-30  random  factor  for  dry  bulk  cargo 
vessels '  port  turnaround  time 
31-40  random  factor  for  train  vessel’s 
port  turnaround  time 
41-50  random  factor  for  liquid  cargo 
vessel's  port  turnaround  time 


Note:  the  factors  given  above  are  interpreted 


as  the  mean  of  an  exponential  distribution  in 


NETSIM  II. 


The  following  are  in  10-column  fields,  integer, 

right  justified  (3  I  10), 

cc  1-10  port  identification  number 
11-20  dry  bulk  cargo  queue  limit 
21-30  liquid  bulk  cargo  queue  limit 

Note:  when  the  number  of  vessels  awaiting  cargo 
is  greater  than  the  limit,  all  other  vessels  of 
that  type  are  sent  back  to  their  origins  empty 
after  unloading. 

The  following  are  in  10-column  fields,  integer, 
right  justified  (5  I  10). 
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Item 

Number 


Contents 


Bll 


cc 


1-10  port  identification  number 
11-20  number  of  general  cargo  berths 
21-30  number  of  dry  bulk  (excluding 
grain)  berths 

31-40  number  of  grain  berths 
41-50  number  of  liquid  bulk  berths 


For  a  system  with  n  commodities,  the  format  is 
(I  10,  D  n(5,2)  ),  right  justified. 


1-T0 

port  identification  number 

13-15 

*xx  probability  of  empty  backhaul 

for  commodity  1 

18-20 

•XX 

23-25 

•  XX 

28-30 

•  XX 

Items  B12  through  B16  in  entirety  must  be 
repeated  for  each  lake  until  all  the  lakes  are 
exhausted. 

B12  ID.  LAKE 

Identification  number  of  lake. 

B13  NUM. OF. LAKE. NODES 

The  number  of  nodes  (including  ports)  on  lake. 

B14  LAK. PARA. CODE 

This  code  is  1  if  the  lake  is  part  of  a  parallel 
routes  set,  0  otherwise. 

B15  CDF.LTT 

This  code  is  1  if  the  lake  transit  time  distrib¬ 
ution  is  specified  empirically,  0  if  a  theoretical 
distribution  is  to  be  used. 


Item 

Number 


Contents 


B16  Lake  transit  time  distribution 

Note:  Transit  times  for  passage  through  lakes 
should  normally  be  supplied  through  the  INTRALAKE. 
TRAVEL. TABLE.  In  certain  simulations  where  lakes 
are  simplistically  represented,  however,  it  may  be 
easier  to  specify  the  use  of  a  theoretical  function 
without  great  loss  of  accuracy.  For  example, 
representation  of  Lake  St.  Francis  on  the  St. 
Lawrence  Seaway  as  a  lake  (rather  than  a  reach) 
may  warrant  a  theoretical  function  to  calculate 
travel  time  from  one  end  of  the  lake  to  the  other. 


Theoretical  distribution. 

This  specification  requires  five  elements: 

1st  element  <=  lake  identification  number 
2nd  element  =  NETSIM  II  code  for  SIMSCRIPT 
function  (refer  to  Table  A-l) 

3-5  elements  =  parameters^  of  SIMSCRIPT  function 
(refer  to  Table  A-l). 

INTRALAKE . TRAVEL .TABLE 

The  table  is  read  row  by  row.  The  first  row  con¬ 
tains,  in  its  first  column,  the  identification 
number  of  the  lake.  Columns  2  through  n  +  1  of 
the  first  row  contain  the  identification  numbers 
of  each  of  the  n  nodes  on  the  lake.  The  first 
column  of  rows  2  through  n  +  1  contains  the 
identification  numbers  of  each  of  the  n  nodes. 
Columns  2  through  n  +  1  of  rows  2  through  n  +  1 
contain  the  average  transit  time  between  each 
pair  of  nodes. 


If  the  5th  element  is  not  required  for  the  function,  it  must  still  be 
input  as  0. 


UNIFORM  Beginning  Value  Ending  Value 


Item 

Number 


B17 

B18 

B19 

B20 

B21 

B22 

B23 


Contents 

Note:  the  user  cannot  supply  both  the 
theoretical  function  and  the  INTRALAKE . TRAVEL . 
TABLE;  only  one  of  the  choices  must  be  supplied. 

Items  B17  through  B25  in  entirety  must  be 
repeated  for  each  reach  until  all  the  reaches 
are  exhausted. 

ID. REACH 

Identification  number  of  the  reach. 

LENGTH 

Length  of  the  reach  in  miles. 

PASS. RULE 

The  passing  rule  is  1  if  passing  is  allowed  in 
the  reach,  0  otherwise. 

RCH. PARA. CODE 

This  code  is  1  if  the  reach  is  part  of  a  parallel 
routes  set,  0  otherwise. 

CDF.RTT 

This  code  is  1  if  the  reach  transit  time  dis¬ 
tribution  is  specified  empirically,  0  if  a 
theoretical  function  is  to  be  used. 

UP STREAM. NODE 

Upstream  node  of  the  reach. 

DOWNSTREAM. NODE 

Downstream  node  of  the  reach. 


Item 

Number 


Contents 


B24  Reach  transit  time  distribution 

Theoretical  distribution 

This  specification  requires  five  elements  for 
each  direction  of  travel.  The  downstream 
function  must  precede  the  upstream  function. 

1st  element  =  reach  identification  number 
2nd  element  =  NETSIM  II  code  for  SIMSCRIPT 
function  (refer  to  Table  A-l) 

3-5  elements  =  parameters^  of  SIMSCRIPT 

function  (refer  to  Table  A-l) . 

Empirical  distribution 

This  specification  requires  two  distributions, 
one  for  each  direction  of  travel.  The  dis¬ 
tributions  must  be  supplied  as  pairs  of  data 
values  where  the  first  of  each  pair  is  the 
probability  and  the  second  is  the  sample  value. 
Input  probabilities  can  be  cumulative  or  indi¬ 
vidual.  At  the  end  of  each  distribution  a 
blank  space  must  be  followed  by  an  asterisk  (*). 
The  downstream  function  must  precede  the  upstream 
function. 

Note:  the  user  cannot  specify  both  the 

theoretical  and  the  empirical  functions;  only 

one  of  the  choices  must  be  supplied. 

B25  ETT  Functions 

This  specification  requires  four  elements  for 
each  direction  of  travel.  The  downstream 
function  must  precede  the  upstream  function. 

The  functions  can  be  given  in  real  format. 

1st  element  =  reach  identification  number 
2nd  element  =  reach  end  node  (upstream  node 
for  the  downstream  function 
and  downstream  node  for  the 
upstream  function) 

3rd  element  =  statistical  coefficient  represent¬ 
ing  the  effect  of  the  reach  traffic 
on  expected  transit  time 

4th  element  *  statistical  coefficient  represent¬ 
ing  the  effect  of  the  reach  length 
on  expected  transit  time. 


If  the  5th  element  is  not  required  for  the  function, 
It  must  still  be  input  as  0. 
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Item 

Number 


B26 

B27 

B28 

B29 

B30 

B31 


Contents 

Note:  The  ETT  functions  must  not  be  supplied 
if  (1)  this  is  an  EDB  run,  or  (2)  the  reach  is 
not  part  of  a  parallel  routes  set. 

Items  B26  through  B42  in  entirety  must  be 
repeated  for  each  lock  until  all  the  locks  are 
exhausted. 

ID. LOCK 

Identification  number  of  the  lock. 

UP. DIR. NODE 

Upstream  node  of  the  lock. 

DN. DIR. NODE 

Downstream  node  of  the  lock.  I 

MAXIMUM. VESSEL. LENGTH  I 

Maximum  vessel  length  accommodated  in  lock,  | 

expressed  in  tens  of  feet.  g 

LOK. PARA. CODE  I 

This  code  is  1  if  the  lock  is  part  of  a  parallel  I 

routes  set,  0  otherwise.  I 

CDF. MOVING  I 

This  is  a  code  for  long  entry  which  is  0  if  a  I 

theoretical  function  is  to  be  used.  Otherwise,  f 

the  code  must  have  an  integer  value  between  1  I 

and  10  indicating  the  empirical  distribution  I 

that  should  be  used  (see  Item  C5).  I 
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Number 

B32 


B33 


B34 


B35 


B36 


B37 


B38 


Contents 

CDF. SHORT 

This  is  a  code  for  short  entry  to  be  supplied 
as  above. 

CDF . STERN . CLEAR. TIME 

This  is  a  code  for  chamber  exit  to  be  supplied 
as  above. 

CDF. GATE. TO. CP. TIME 

This  is  a  code  for  throat  exit  to  be  supplied 
as  above. 

CDF. CHAMBER 

This  is  a  code  for  chamber  cycle  to  be  supplied 
as  above. 

MOVING. ADJUSTMENT 

This  is  a  percentage  factor  used  to  adjust  an 
average  long  entry  time  of  a  Class  2  vessel 
upward  (for  Class  3  vessels)  or  downward  (for 
Class  1  vessels).  For  example,  an  entry  of 
'15'  would  indicate  that  a  Class  3  vessel 
requires  15  percent  longer  than  a  Class  2 
vessel  and  a  Class  1  vessel  requires  15  percent 
less  time  than  a  Class  2  vessel. 

SHORT. ADJUSTMENT 

This  is  a  percentage  factor  used  to  adjust  short 
entry  time  as  described  above. 

STERN . CLEAR. ADJUSTMENT 

This  is  a  percentage  factor  used  to  adjust 
chamber  exit  as  described  above. 
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Number 


Contents 


B39  GATE. TO. CP. ADJUSTMENT 

This  is  a  percentage  factor  used  to  adjust 
throat  exit  as  described  above. 

B40  CHAMBER. ADJUSTMENT 

This  is  a  percentage  factor  used  to  adjust 
chamber  cycle  as  described  above. 

B41  Locking  time  frequency  distributions 

These  distributions  may  be  specified  as 
empirical  or  theoretical  functions. 

Theoretical  distribution 

This  specification  requires  five  elements  for 
each  locking  time  segment.  The  order  of  input 
is  as  follows: 

Long  Entry 
Short  Entry 
Chamber  Cycle 
Chamber  Exit 
Throat  Exit 

1st  element  =  lock  identification  number 
2nd  element  =  NETSIM  II  code  for  SIMSCRIPT 
function  (refer  to  Table  A-l) 

3-5  elements  =  parameters-*  of  SIMSCRIPT 

function  (refer  to  Table  A-l) . 

Empirical  distribution 

NETSIM  II  allows  up  to  ten  distributions  for 
each  locking  time  segment.  Theue  data  are  not 
read  at  this  point  in  the  data  deck  but  rather 
under  Item  C5. 

Note:  The  user  cannot  specify  both  the 
theoretical  and  the  empirical  functions;  only 
one  of  the  choices  must  be  supplied. 

3 

If  the  5th  element  is  not  required  for  the  function,  it  must  still 
be  input  as  0. 
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ETT  Functions 

This  specification  requires  four  elements 
for  each  direction  of  travel.  The  downstream 
function  must  precede  the  upstream  function. 

The  functions  can  be  given  in  real  format. 

1st  element  =  lock  identification  number 
2nd  element  =  lock  end  node  (upstream  node  for 
the  downstream  function  and  down¬ 
stream  node  for  the  upstream 
function) 

3rd  element  =  statistical  coefficient  represent¬ 
ing  the  effect  of  the  near  queue 
(upstream  queue  for  the  downstream 
function  and  vice  versa)  size  on 
expected  transit  time 

4th  element  =  statistical  coefficient  represent¬ 
ing  the  effect  of  the  far  queue 
(downstream  queue  for  the  down¬ 
stream  function  and  vice  versa) 
size  on  expected  transit  time. 

Note:  The  ETT  functions  must  not  be  supplied  if 

(1)  this  is  an  EDB  run,  or  (2)  the  lock  is  not 

part  of  a  parallel  routes  set. 

STAT. ADDITIVE 

This  is  a  percentage  additive  factor  used  to 
adjust  long  entry  to  reflect  chamber  entry  from 
a  stationary  position  at  queue;  set  to  0  if 
not  desired.  Thus,  an  entry  of  '15'  would 
indicate  that  a  long  entry  from  a  stationary 
position  consumes  15  percent  greater  time  than 
a  long  entry  from  a  moving  position. 

ARE. SENTRY. PROPORTION 

This  is  a  percentage  proportion  used  to  adjust 
long  entry  to  reflect  arrival  time  to  a  short 
entry  position  at  lock  gates  from  the  lock  clear 
point;  set  to  0  if  not  desired.  Thus,  an  entry 
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Number 


Contents 


of  '60'  would  indicate  that  the  time  to  arrive 
at  short  entry  position  from  the  lock  clear 
point  is  60  percent  of  the  time  for  long  entry 
into  chamber. 

B45  QUE. SENTRY. ADDITIVE 

This  is  a  percentage  additive  factor  used  to 
adjust  the  time  segment  in  Item  B44  (arrival 
time  to  short  ent  ry  position)  to  reflect  arrival 
time  to  a  short  entry  position  from  a  stationary 
position  at  queue;  set  to  0  if  not  desired. 

B46  PROCESS. ADDITIVE 

This  is  a  percentage  additive  factor  used  to 
adjust  the  chamber  cycle  to  reflect  a  locking 
process  (i.e.,  a  cycle  with  the  chamber  occupied 
as  opposed  to  an  empty  cycle) ;  set  to  0  if  not 
desired. 

Cl  TABLE. OF. NEXT. NODES 

This  is  a  m  x  n  matrix  where  m  is  the  number  of 
all  nodes  in  the  system  fi.e.,  including  ports) 
and  n  is  the  number  of  ports.  The  table  is  read 
row  by  row  and  each  cell  contains  the  identifica¬ 
tion  number  of  the  next  node  encountered  in 
traveling  from  the  ith  node  to  the  jth  port. 

In  the  event  that  parallel  routes  are  present, 
each  route  must  be  given  an  identification 
number  which  is  greater  than  1000  but  less  than 


Item 

Number 


C2 


C3 


C4 


4 

All  three  tables 
to  a  single  card 


Contents 

9999  and  the  entry  in  the  TABLE. OF. NEXT. NODES 
must  be  the  first  of  these  route  identification 
numbers  (the  order  of  the  routes  is  determined 
by  their  entry  in  the  PARALLEL. FACILITIES. TABLE) . 
FACILITIES . ID. TABLE 

This  is  the  lower  triangle  of  a  m  x  m  matrix 
where  m  is  the  number  of  all  system  nodes.  The 
table  is  read  row  by  row  and  each  cell  contains 
the  identification  number  of  the  facility 
between  each  pair  of  consecutive  nodes.  For 
each  pair  of  non-consecutive  nodes,  the  entry 
must  be  0. 

NO. OF. ROWS 

This  is  the  number  of  parallel  routes  in  the 
system. 

PARALLEL. FACILITIES . TABLE 

This  is  a  jagged  array  consisting  of  two  parts. 
The  first  part  describes  each  parallel  route,  row 
by  row.^  The  second  part  provides  the  ETT 
functions  for  each  route. 

Route  Description 

The  table  is  read  row  by  row  and  ear.h  row  in 
this  first  part  of  the  table  describes  a  route 
which  is  part  of  a  parallel  set.  The  length  of 
each  row  is  dependent  upon  the  number  of  nodes 
present  in  the  route,  however,  all  rows  have 
four  common  elements  as  seen  below. 


are  read  row  by  row  and  a  row  is  not  confined 
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Contents 


A  row  consists  of  the  following  elements: 

1st  element  =  identification  number  of  the  route 
2nd  element  =  number  of  routes  within  a  parallel  set 
Zed  element  =  probability  of  selecting  this 

route,  expressed  in  percent,  for 
an  EDB  simulation 

4th  element  =  number  of  nodes  on  this  route 
5th  element  =  upstream  node  of  the  route 
6th  element  =  identification  number  of  the 
next  facility 

7th  element  =  next  node  number 
8th  element  =  next  facility 


last  element  =  downstream  node  of  the  route. 

Note:  the  5th  through  the  last  element  in  each 

row  describe  a.  route  completely  in  terms  of 

links  and  nodes.  Starting  with  the  upstream  node, 

each  link  and  node  is  listed  in  order  up  to  and 

including  the  downstream  node.  The  user  may 

verify  that  the  upstream  and  downstream  nodes 

will  be  common  across  all  routes  within  a  parallel 

set. 

ETT  Functions 

This  specification  is  given  route  by  route  with 
each  route  requiring  two  ETT  functions,  one  for 
each  direction  of  travel,  and  each  function 
requiring  six  elements.  The  downstream  function 
must  precede  the  upstream  function.  The  functions 
can  be  given  in  real  format. 

1st  element  =  route  identification  number 
2nd  element  =  end  node  (upstream  node  for 
downstream  function  and  vice 
versa) 

3rd  element  *  statistical  coefficient  represent¬ 
ing  the  effect  of  the  length  of 
the  vessel  on  expected  transit  time 
4th  element  =  statistical  coefficient  represent¬ 
ing  the  effect  of  the  draft  of  the 
vessel  on  expected  transit  time 


Item 

Number 


Contents 


5th  element  =  statistical  coefficient  represent¬ 
ing  the  effect  of  the  route 
traffic  (number  of  vessels  on 
route)  on  expected  transit  time 
6th  element  =  statistical  coefficient  represent¬ 
ing  the  intercept  term  in  the  ETT 
function. 

Note:  The  ETT  functions  (that  is,  the  second 
part  of  the  PARALLEL. FACILITIES .TABLE)  must  not 
be  supplied  for  an  EDB  run. 


C5  Empirical  locking  time  distributions. 

NETSIM  II  allows  up  to  ten  distributions  for 
each  of  the  five  locking  time  segments.  A  set 
of  distributions  is  a  collection  of  five  dis¬ 
tributions,  one  for  each  segment.  The  distri¬ 
butions  are  provided  by  sets,  i.e.,  the  user 
must  supply  a  distribution  for  each  segment  in 
a  set  before  supplying  the  next  set.  Each  dis¬ 
tribution  is  specified  as  pairs  of  data  values 
where  the  first  of  each  pair  is  the  probability 
and  the  second  is  the  sample  value.  Input 
probabilities  can  be  cumulative  or  individual. 

At  the  end  of  each  distribution  a  blank  space 
must  be  followed  by  as  asterisk  (*). 

Note:  These  empirical  distributions  should  not 

be  supplied  if  theoretical  functions  for  locking 

time  segments  have  been  specified  in  Item  B41. 


D1  COMMODITY  ARRIVALS 

The  commodity  arrivals  are  exogenous  events  in 
NETSIM  II.  As  such,  they  are  introduced  into 
the  system  through  the  external  event  notices 
which  have  special  format. 
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Item 

Number  Contents 


Card  Type  Columns 


Description 


1 


2 


1-11  Characters  "COM. ARRIVAL" 

12-20  Simulation  time  at  which  the 

commodities  are  to  arrive  in 
port.  This  is  in  real  format 
so  that  the  decimal  point  must 
always  be  present. 

1-10  Port  number  into  which  the 

commodity  is  to  be  introduced 
11-20  Commodity  type 

21-30  Destination  (port  number) 

31-40  Commodity  quantity  in  hundreds 

of  tons . 


Note: 


There  will  be  one  type 


card  for  each 


port-commodity-destination  combination.  The  type  2 
cards  must  be  sequenced  in  increasing  order  by 
commodity  type  within  port  number.  The  last  type 
2  card  must  have  zeroes  in  all  four  fields  to 


signal  end  of  data. 

3  1  Character  "*"  to  signal  end 

of  event  data  notices. 


This  sequence  of  card  types  is  repeated  for  every 
event  data  notice,  i.e.,  for  every  commodity 
arrival  notice  occurring  at  a  different  and 
higher  simulation  time.  Note  that  the  external 
event  data  notices  ascend  in  simulation  time. 


Note  also  that  the  commodity  arrivals  data  must 
be  submitted  on  the  COMM. DEVICE  (Item  A30)  unit. 


5 


All  data  in  type  2  cards  are  integer  and  right  justified. 
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Item 

Number  Contents 

El  VESSEL  INTRODUCTIONS 

The  vessel  introductions  are  also  exogenous 
events  in  NETSIM  II  and  thus  are  handled  through 
the  external  data  event  notices.  In  this  case, 
the  entire  event  notice  can  be  fit  on  one  80- 
column  card  with  the  following  format. 

Columns  Description 

1-12  Characters  "CREAT. VESSEL" 

13-20  Simulation  time  at  which  vessels  are 

to  be  introduced  into  the  system. 

This  is  in  real  format  so  that  the 

decimal  point  must  always  be  present. 

Except  as  noted,  the  following  fields  are 
integer  and  right  justified. 

21-23  Number  of  the  port  at  which  the 

vessel  is  to  be  introduced. 

24-27  Vessel  length  in  tens  of  feet. 

28-33  Vessel  horsepower  in  hundreds  of 

horsepower. 

34-39  Capacity  of  vessel  in  hundreds  of  tons. 

40-44  Unloading  rate  in  hundreds  of  tons 

per  minute  (for  self-unloaders  only, 
otherwise  0).  (Decimal  format). 

45-47  Draft  of  vessel  in  feet. 

48-49  Vessel  classification  (1  *  saltwater; 

2  ■  liquid  bulk;  3  ■  dry  bulk). 
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Item 

Number 


Contents 


Columns 

50-53 

54-59 

60-61 

62-65 

66-71 


75 


Description 

Code  to  indicate  backhaul  journey 
(can  be  set  to  0). 

Commodity  tonnage  in  hundreds  of 
tons  (can  be  set  to  0) . 

Commodity  type  (can  be  set  to  0). 
Origin  (port  number) . 

Vessel  identification  number — vessels 
should  be  numbered  sequentially 
beginning  with  1. 
asterisk. 


A  card  format  as  indicated  above  must  be  prepared 
for  every  vessel  to  be  introduced  into  the 
system  during  simulation.  These  cards  must  be 
ascending  order  ranked  by  simulation  entry  time 
(cc  13-20)  and  mua_  be  submitted  on  the  SHIP. DEVICE 
(Item  A31)  unit. 


D.  OUTPUT 

Although  the  primary  output  of  a  NETSIM  II  simulation  run  is  the  event 
log,  a  different  output  is  generated  for  an  EDB  simulation  run.  The  latter, 
of  course,  is  used  to  provide  the  statistical  base  for  deriving  the  ETT 
functions  for  systems  with  parallel  route  options.  The  third  type  of  output 
is  the  commodity  inventory  level  report. 


-85- 


1.  EDB  Output 


The  EDB  output  functionally  consists  of  two  parts.  The  first  part 
generates  data  for  the  EDB  usage  parameters  when  a  vessel  arrives  at  a 
particular  channel  choice  point  in  the  system.  These  usage  parameters  are 
system  conditions  such  as  vessel  traffic  present  at  reach  and  lock  facilities 
on  a  particular  route  which  is  part  of  the  parallel  routes  set.  The  second 
part  provides  the  entry  and  exit  times  through  each  such  facility  during  a 
vessel's  passage  on  that  route.  Thus,  the  actual  transit  time  through  a 
route  may  be  statistically  related  to  the  usage  parameters,  i.e.,  the  systems 
conditions  present  when  a  vessel  had  initially  arrived  at  the  basis  of  the 
route. 

The  output  format  is  as  follows  (314,11,14,17,  D(7,0)  ): 


Description 


Item 

Colunai 

Format 

Part  1 

Part  2 

1 

1-4 

I  4 

Vessel  identification 

Vessel  identification 

number 

number 

2 

5-8 

I  4 

Vessel  length  (in  tens 

Vessel  length  (in  tens 

of  feet) 

of  feet) 

3 

9-12 

I  4 

Current  node  of  vessel 

Current  node  of  vessel  > 

4 

13 

I  1 

1 

2  j 

5 

14-17 

I  4 

Facility  identification 

Facility  identification 

number 

number 

6 

18-24 

I  7 

Usage  parameter 

Entry  time 

7 

25-31 

D(7,0) 

Usage  parameter 

Exit  time 

Note:  Item  6  Usage  parameter  in  Part  1  may  be  one  of 

the  following: 

For  a 

lock,  this 

parameter  is  the  near  queu' 

For  a 

reach,  this 

parameter  is  the  number  o: 

Is  in  reach. 

Item  7  Usage  parameter  in  Part  1  may  be  one  of  the  following: 

For  a  lock,  this  parameter  is  the  far  queue  size. 

For  a  reach,  this  parameter  is  not  used  and  is  set  to  0. 


2.  Event  Log 

The  event  log  consists  of  a  detailed  card  that  records  significant 
attributes  for  each  event  that  occurs  during  the  simulation  and  describes 


each  event  by  an  event  code.  Each  event  log  record  contains  eleven 
elements  with  the  following  format  (414,13,11,12,11,214, 
D(7,0)  ). 


Item 

Column 

Format 

Description 

1 

1-4 

I  4 

Vessel  identification  number 

2 

5-8 

I  4 

Vessel  length  in  tens  of  feet 

3 

9-12 

I  4 

Vessel's  current  node  number 

4 

13-16 

I  4 

Vessel's  next  node  number 

5 

17-19 

I  3 

Vessel's  cargo  tonnage  in  hundreds  of  tons 

6 

20 

I  1 

Commodity  type 

7 

21-22 

I  2 

Code  for  dedicated  cargo 

8 

23 

I  1 

Vessel  classification  (1  =  saltwater; 

2  =  liquid  bulk;  3  =  dry  bulk) 

9 

24-27 

I  4 

Facility  identification  number 

10 

28-31 

I  4 

Event  code 

11 

32-38 

D(7,0) 

Simulation  time 

EVENT  CODES 

The  event  codes  are  four  digit  numerals  that  completely  describe  a 
simulation  event  in  system  dynamics.  The  event  codes  have  been  categorized 
by  changes  in  system  status.  However,  within  each  category  the  level  of 
detail  in  describing  system  dynamics  can  enable  the  user  to  inspect  manually 
the  event  log  and  interpret  the  simulation.  The  event  code  categories  are 
presented  first  since  they  form  a  useful  summary  of  the  event  log  output. 
This  is  followed  by  a  description  of  each  event  code. 


Event  Code  Categories 


Series 

Entity 

Description 

1100 

LOCK 

Enter  queue 

1200 

Begin  entry  towards  short  entry 
position 

1300 

Begin  entry  towards  chamber 

Series 

Entity 

Description 

1400 

Exit  queue  to  begin  entry  towards 
chamber 

1500 

Exit  queue  to  begin  entry  towards 
short  entry  position 

1600 

Arrive  at  short  entry  position 

1700 

Exit  short  entry  position  to  begin 
entry  towards  chamber 

1800 

• 

Exit  lock 

2000 

Arrive  in  chamber 

2100 

Begin  chamber  exit 

2200 

Chamber  end  cycle — vicinity  empty 

2300 

Chamber  end  cycle — vicinity  not  empty 

2400 

Begin  throat  exit 

3101 

LAKE 

Enter  lake 

3102 

Exit  lake 

4101 

REACH 

Enter  reach 

4102 

Exit  reach 

5101 

WELLAND 

Enter  queue 

5102 

Enter  locks 

5103 

Exit  locks  and  enter  channels 

5104 

Exit  Welland 

9100 

PORT 

Enter  port 

9110 

Enter  cargo  queue 

9120 

Exit  cargo  queue 

9130 

Enter  berth  queue 

9140 

Exit  berth  queue 

9150 

Enter  berth 

9160 

Exit  berth 

88- 


Series 


Entity 


Description 


9170  Exit  port 

9180  Saltwater  vessel  departs  port  for 

lack  of  cargo 

9190  Bulk  vessel  dispatched  to  nearby 

port  to  load  cargo 


Event  Codes  Description 

Notes:  The  following  terminology  is  used  in  the  event  code  descriptions. 
MOVING. TXT  =  long  entry  time 

STATIONARY. TTT  »  long  entry  time  modified  by  an  additive  factor 

(Item  B43)  to  reflect  long  entry  into  the  chamber 
from  a  stationary  position  at  queue. 

SHORT. TTT  =  short  entry  time. 


Code  Description 

Decision-triggering  event:  Arrive  at  lock 
Resultant  action:  enter  near  queue 


1100  Near  queue,  near  throat,  chamber  are  empty.  Water  level  at  the 
moment  is  correct,  but  chamber  is  recycling  to  the  other  side. 

1101  Near  queue  is  not  empty. 

1102  Near  queue  is  empty.  Near  throat  is  not  empty. 

1103  Near  queue  and  near  throat  are  empty.  Chamber  contains  a 
vessel  sailing  toward  arrival  vessel. 

1104  Near  queue  and  near  throat  are  empty.  Chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel.  Far 
queue  is  not  empty. 

1105  Near  queue  and  near  throat  are  empty;  chamber  is  empty;  water 
level  is  not  okay;  far  throat  is  empty;  far  queue  is  not  empty. 
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Code 


1106 

1107 

1108 

1109 

1110 
1111 

1112 


1113 

1114 

1115 

1116 


1117 


Description 

Near  queue  and  near  throat  are  empty;  chamber  is  empty;  water 
level  is  not  okay;  far  throat  contains  a  vessel  sailing  in 
same  direction  as  arrival  vessel;  far  queue  is  not  empty. 

Near  queue  and  near  throat  are  empty;  chamber  is  empty;  water 
level  is  not  okay;  far  throat  contains  a  vessel  sailing 
toward  arrival  vessel. 

Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel;  far  queue 
is  empty;  service  look-ahead  feature  is  used;  far  reach  con¬ 
tains  a  vessel  which  can  sail  into  chamber  before  arrival 
vessel;  reach  vessel  uses  MOVING. TIT  and  arrival  vessel  uses 
SHORT. TTT  for  comparison. 

Same  as  1108  above  except  that  arrival  vessel  uses  MOVING. TTT. 

Same  as  1108  above  except  that  reach  vessel  uses  STATIONARY. TTT. 

Same  as  1108  above  except  that  reach  vessel  uses  STATIONARY . TTT 

and  arrival  vessel  uses  MOVING. TTT. 

Near  queue  and  near  throat  are  empty;  chamber  is  empty  and  is 
not  now  scheduled  for  recycling;  water  level  is  not  okay;  far 
throat  contains  a  vessel  sailing  in  same  direction  as  arrival 
vessel;  service  look-ahead  feature  is  used;  chamber  has  not 
been  free  long  enough  to  complete  recycling  before  arrival 
could  be  in  chamber;  far  reach  contains  a  vessel  which  can 
sail  into  chamber  before  arrival;  reach  vessel  uses  STATIONARY. TTT 
and  arrival  vessel  uses  SHORT. TTT  for  comparison. 

Same  as  1112  above  except  that  arrival  uses  MOVING. TTT. 

Same  as  1112  above  except  that  reach  vessel  uses  MOVING. TTT. 

Same  as  1112  above  except  that  reach  vessel  uses  MOVING. TTT 

and  arrival  vessel  uses  MOVING. TTT. 

Near  queue  and  near  throat  are  empty;  chamber  is  empty  and  is 
not  now  scheduled  for  recycling;  water  level  is  not  okay;  far 
throat  is  empty;  service  look-ahead  feature  is  used;  chamber 
has  not  been  free  long  enough  to  have  now  recycled;  chamber 
has  not  been  free  long  enough  to  complete  recycling  before 
arrival  vessel  could  enter  chamber;  far  reach  contains  a 
vessel  which  can  sail  into  chamber  before  arrival  vessel; 
reach  vessel  uses  MOVING. TTT  and  arrival  vessel  uses  SHORT. TTT. 

Same  as  1116  above  except  that  chamber  has  been  free  long 
enough  to  complete  recycling  before  arrival  could  enter 
chamber,  so  that  arrival  vessel  uses  MOVING. TTT. 
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Code 


Description 

1118  Same  as  1116  above  except  that  chamber  has  been  free  long 

enough  to  have  now  recycled,  so  that  arrival  vessel  uses 
MOVING. TTT. 


Decision-triggering  event:  Arrive  at  lock 
Resultant  action:  Move  to  short-entry  position 


1201  Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel;  far 
queue  is  empty;  service  look-ahead  feature  is  not  used; 
chamber  is  now  recycling  but  is  not  able  to  recycle  before 
vessel  would  enter  chamber  using  MOVING. TTT. 

1202  Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  not  used;  chamber  is  recycling 
but  will  not  complete  recycle  before  arrival  could  move  into 
chamber. 

1203  Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  not  used;  chamber  is  not  now 
recycling;  chamber  is  now  scheduled  to  recycle,  but  recycling 
would  not  be  completed  before  arrival  vessel  could  move  into 
chamber. 

1204  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  and  look-ahead  feature  is  not  used;  chamber  is  not 
now  cycling  nor  is  it  now  scheduled  for  recycling;  chamber 
has  not  been  free  long  enough  to  have  completed  recycling 
before  arrival  vessel  could  move  into  chamber. 

1205  Near  queue,  near  throat,  and  far  queue  are  empty;  chamber 
contains  a  vessel  moving  in  same  direction  as  arrival  vessel; 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  would  not  be  able  to  complete  process  and  recycle 
before  vessel  could  move  into  chamber. 

1206  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  is  now  scheduled  for  recycling,  but  it  will  not  be 
completed  before  arrival  vessel  could  move  into  chamber. 

1207  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  is  not  now  scheduled  for  recycle,  nor  is  it  now 
recycling,  chamber  has  not  been  free  long  enough  to  have 
completed  recycling  before  arrival  vessel  could  move  into 
chamber. 


Code  Description 

1208  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty, 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  is  now  recycling,  but  will  not  complete  recycle 
before  arrival  vessel  could  move  into  chamber. 

1209  Near  queue,  near  throat,  and  far  queue  are  empty,  chamber 
contains  a  vessel  moving  in  same  direction  as  arrival  vessel; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  vessel  from  next  reach 
will  arrive  at  clear  point  after  chamber  vessel  (therefore 
uses  MOVING. TTT);  chamber  cannot  complete  processing  and 
recycle  before  arrival  could  have  moved  into  chamber  (there¬ 
fore  uses  SHORT. TTT);  vessel  from  next  reach  cannot  be  in 
chamber  before  arrival  vessel. 

1210  Near  queue,  near  throat,  and  far  queue  are  empty;  chamber 
contains  a  vessel  moving  in  same  direction  as  arrival  vessel; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  reach  vessel  will 
arrive  at  clear  point  before  chamber  vessel  (therefore  reach 
vessel  uses  STATIONARY. TTT) ;  chamber  cannot  complete  proces¬ 
sing  and  recycle  before  arrival  could  have  moved  into  chamber 
(therefore  arrival  uses  SHORT. TTT);  reach  vessel  cannot  be 

in  chamber  before  arrival  vessel. 

1211  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival;  chamber  is  now  recycling,  but 
will  not  finish  before  arrival  could  have  moved  into  chamber. 

1212  Same  as  1211  except  that  chamber  is  not  now  recycling;  chamber 
has  been  scheduled  for  recycling,  but  will  not  complete 
recycle  before  arrival  vessel  could  have  moved  into  chamber. 

1213  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  chamber  is  not  now 
scheduled  for  recycling  nor  is  it  now  recycling;  far  throat 
contains  a  vessel  sailing  in  same  direction  as  arrival  vessel; 
reach  vessel  will  arrive  at  clear  point  before  throat  vessel 
(therefore  reach  vessel  uses  STATIONARY. TTT) ;  chamber  has  not 
been  free  long  enough  to  have  recycled  before  arrival  vessel 
could  have  moved  into  chamber  (therefore  arrival  vessel  uses 
SHORT. TTT);  reach  vessel  cannot  be  in  chamber  before  arrival 
vessel. 

1214  Same  as  1213  except  that  reach  vessel  will  not  arrive  at 
clear  point  before  throat  vessel  (therefore  reach  vessel 
uses  MOVING. TTT). 
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Code 


Description 

1215  Near  queue,  near  throat,  chamber,  far  throat,  and  far  queue 

are  empty;  service  look-ahead  feature  is  used,  next  reach 
contains  a  vessel  sailing  toward  arrival  vessel;  chamber  is 
not  now  recycling  nor  is  it  now  scheduled  to  recycle;  chamber 
has  not  been  free  long  enough  to  have  now  recycled;  chamber 
has  not  been  free  long  enough  to  have  recycled  before  arrival 
could  be  in  chamber  (so  arrival  uses  SHORT. TIT);  reach  vessel 
cannot  be  in  chamber  before  arrival  vessel. 


Decision-triggering  event:  Arrive  at  lock 
Resultant  action:  Move  directly  into  chamber 


1301  Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel;  far  queue 
is  empty;  service  look-ahead  feature  is  not  used;  chamber  is 
now  recycling  and  will  complete  cycle  before  arrival  could 
move  into  chamber. 

1302  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
far  throat  is  either  empty  or  contains  a  vessel  sailing  in 
same  direction  as  arrival  vessel;  service  look-ahead  feature 
is  not  used;  chamber  is  now  recycling  and  will  complete  cycle 
before  arrival  vessel  could  have  moved  into  chamber. 

1303  Same  as  1302  except  that  chamber  is  not  now  recycling;  chamber 
is  now  scheduled  to  recycle  and  will  complete  recycling  before 
arrival  vessel  could  have  moved  into  chamber. 

1304  Same  as  1302  except  that  chamber  is  neither  now  recycling  nor 
scheduled  for  recycling;  chamber  has  been  free  long  enough  to 
have  recycled  before  arrival  vessel  could  have  entered  chamber. 

1305  Near  queue,  near  throat,  and  far  queue  are  empty;  chamber 
contains  a  vessel  sailing  in  same  direction  as  arrival  vessel; 
service  look-ahead  feature  is  used;  next  reach  has  no  vessel 
sailing  toward  arrival  vessel;  chamber  is  now  processing  and 
will  be  able  to  complete  process  and  recycle  before  arrival 
could  move  into  chamber. 

1306  Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
look-ahead  feature  is  used;  next  reach  contains  no  vessel 
sailing  toward  arrival  vessel;  chamber  is  now  scheduled  to 
recycle  and  will  complete  recycling  before  arrival  vessel 
could  move  into  chamber. 

1307  Same  as  1306  except  that  chamber  is  neither  now  scheduled  to 
recycle  nor  is  now  recycling;  chamber  has  been  free  long 
enough  to  have  completed  recycling  before  arrival  vessel 
could  move  into  chamber. 
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Code 


1308 

1309 

1310 

1311 

1312 

1313 

1314 


Same  as  1306  except  that  chamber  is  no  .  now  scheduled  to 
recycle  but  is  now  recycling  and  will  complete  recycling 
before  arrival  vessel  could  move  into  chamber. 


Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel,  service 
look-ahead  feature  is  used;  next  reach  contains  a  vessel 
sailing  toward  arrival  vessel;  reach  vessel  arrives  at 
clear  point  after  chamber  vessel  (reach  vessel  uses  MOVING. TTT); 
chamber  is  able  to  complete  processing  and  recycle  before 
arrival  vessel  could  have  entered  chamber  (arrival  vessel 
uses  MOVING. TTT);  reach  vessel  cannot  be  in  chamber  before 
arrival  vessel. 


Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel;  service 
look-ahead  feature  is  used;  next  reach  contains  a  vessel 
sailing  toward  arrival  vessel;  reach  vessel  arrives  at  clear 
point  before  chamber  vessel  (reach  vessel,  therefore,  uses 
STATIONARY. TTT) ;  chamber  is  able  to  complete  processing  and 
recycle  before  arrival  vessel  could  have  entered  chamber 
(arrival  vessel,  therefore,  uses  MOVING. TTT);  reach  vessel 
cannot  be  in  chamber  before  arrival  vessel. 


Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival;  chamber  is  now  recycling  and 
will  complete  cycle  before  arrival  vessel  could  have  moved 
into  chamber. 


Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival;  chamber  is  not  now  recycling, 
but  is  now  scheduled  for  recycling  and  will  complete  recycle 
before  arrival  vessel  could  move  into  chamber. 


Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
far  throat  contains  a  vessel  sailing  in  same  direction  as 
arrival  vessel;  service  look-ahead  feature  is  used;  next 
reach  contains  a  vessel  sailing  toward  arrival  vessel;  chamber 
is  not  now  recycling,  nor  is  it  now  scheduled  for  recycling, 
reach  vessel  arrives  at  clear  point  before  throat  vessel 
(reach  vessel,  therefore,  uses  STATIONARY. TTT) ;  chamber  has 
been  free  long  enough  to  have  recycled  before  arrival  vessel 
could  have  entered  chamber  (arrival  vessel,  therefore,  uses 
MOVING. TTT);  reach  vessel  cannot  be  in  chamber  before  arrival 
vessel. 


Same  as  1313  except  that  reach  vessel  does  not  arrive  at  clear 
point  before  throat  vessel  (reach  vessel,  therefore,  uses 
STATIONARY .TTT) . 
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Code 


1315 


1316 


1317 


Near  queue,  near  throat,  chamber,  far  throat,  and  far  queue 
are  empty;  service  look-ahead  feature  is  used;  next  reach 
contains  a  vessel  sailing  toward  arrival  vessel;  chamber  has 
not  been  free  long  enough  to  have  now  recycled,  but  it  has 
been  free  long  enough  to  have  completed  recycling  before 
arrival  vessel  could  have  entered  chamber;  reach  vessel 
cannot  be  in  chamber  before  arrival  vessel. 


Near  queue,  near  throat,  chamber,  far  throat,  and  far  queue 
are  empty;  service  look-ahead  feature  is  used;  next  reach 
contains  a  vessel  sailing  toward  arrival  vessel;  chamber  has 
been  free  long  enough  to  have  now  recycled;  reach  vessel 
cannot  be  in  chamber  before  arrival  vessel. 


Near  queue,  near  throat,  and  chamber  are  empty;  water  level  is 
okay.  Service  look-ahead  feature  is  used. 


Decision-triggering  event:  Exit  queue 
Resultant  action:  Move  into  chamber 


1401  Chamber  is  empty.  Water  level  is  okay. 

1402  Chamber  is  empty.  Water  level  is  not  okay.  Chamber  is  now 

recycling  and  will  complete  cycle  before  vessel  could  move 
into  chamber. 

1403  Chamber  is  empty.  Water  level  is  not  okay.  Chamber  is  not 

now  recycling.  Chamber  is  now  scheduled  to  begin  recycling 
and  will  complete  recycling  before  vessel  could  move  into 
chamber. 


Decision-triggering  event:  Exit  queue 

Resultant  action:  Move  into  short-entry  position 

1501  Chamber  is  not  empty. 

1502  Chamber  is  empty.  Water  level  is  not  okay.  Chamber  is  now 
recycling  but  will  not  complete  cycle  before  vessel  could 
move  into  chamber. 

1503  Chamber  is  empty.  Water  level  is  not  okay.  Chamber  is  not 
now  recycling.  Chamber  is  now  scheduled  to  begin  recycling 
but  will  not  complete  recycling  before  vessel  could  move 
into  chamber. 
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Code 


Description 


Decision-triggering  event:  Move  to  short-entry  position 
1601  Vessel  arrives  at  short-entry  position. 

Decision-triggering  event:  End  cycle 

Resultant  action:  Move  from  short-entry  position  into  chamber 

1701  Chamber  recycled  empty.  Throat  to  which  gates  have  just 

opened  contains  a  vessel. 

Decision-triggering  event:  Transit  throat 

1801  Vessel  exits  lock. 

2001  Vessel  enters  chamber. 

Decision- triggering  event:  End  cycle 
Resultant  action:  Move  to  gates  clear  point 

2101  Chamber  is  not  empty.  Chamber  vessel  begins  chamber  exit. 

Decision-triggering  event:  End  cycle 
Resultant  action:  Chamber  remains  open 

2201  Chamber  recycled  empty.  Throat  and  queue  to  which  gates  have 

just  opened  are  both  empty.  Since  there  is  no  vessel  in  the 
immediate  vicinity,  the  vessel  characteristics  in  the  event 
log  record  are  artificially  given  zero  values. 

Decision-triggering  event:  End  cycle 
Resultant  action:  Chamber  remains  open 
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Code 


Description 

2301  Chamber  recycled  empty.  Throat  to  which  gates  have  just 

opened  contains  a  vessel  moving  into  chamber,  i.e.,  it  is 
not  waiting  in  short-entry  position. 


Decision-triggering  event:  Pass  through  gates  clear  point 
Resultant  action:  Chamber  vessel  exits  to  clearance  point 


2401  Throat  behind  chamber  vessel  is  not  empty.  Therefore, 
chamber  begins  to  recycle. 

2402  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
not  empty. 

2403  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  and 
queue  in  back  are  both  empty.  Service  look-ahead  feature 
is  not  used. 

2404  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  not  empty.  Service  look-ahead 
feature  is  used.  Next  reach  contains  a  vessel  sailing 
toward  lock  which  cannot  move  into  chamber  before  queued 
vessel  could.  Therefore,  chamber  begins  to  recycle  and 
queued  vessel  exits  queue. 

2405  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  not  empty.  Service  look-ahead 
feature  is  used.  Next  reach  contains  a  vessel  sailing 
toward  lock  which  could  move  into  chamber  before  queued 
vessel  could. 

2406  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  not  empty.  Service  look-ahead 
feature  is  used.  Next  reach  does  not  contain  a  vessel 
sailing  toward  lock.  Therefore,  chamber  begins  to  recycle 
and  queued  vessel  exits  queue. 

2407  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  not  empty.  Service  look-ahead 
feature  is  not  used.  Therefore,  chamber  begins  to  recycle 
and  queued  vessel  exits  queue. 


3101  Enter  lake. 

3102  Exit  lake. 
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Code 


Code 

4101 

Enter  reach. 

Description 

4102 

Exit  reach. 

5101 

Enter  Welland  queue. 

5102 

Enter  Welland  locks. 

5103 

Exit  Welland  locks  and 

enter  channels. 

5104 

Depart  Welland. 

- 

9100 

Enter  port. 

9110 

Enter  cargo  queue. 

9120 

Leave  cargo  queue. 

9130 

Enter  berth  queue. 

9140 

Leave  berth  queue. 

9150 

Enter  berth. 

9160 

Leave  berth. 

9170 

Exit  port. 

9180 

Saltwater  vessel  departs  port  for  lack  of  cargo. 

9190 

Bulk  vessel  dispatched 

to  nearby  port  to  load  cargo 

3.  Commodity  Inventory  Level  Report 

Commodity  inventory  levels  are  printed  just  before  each  arrival  of 
commodities  (overland)  into  port.  Hence,  if  commodities  arrive  at  seven 
different  times  during  a  1440  minute  day,  the  commodity  levels  at  each  port 
will  be  printed  out  at  seven  different  times  for  that  day.  Commodities 
are  classified  into  three  groups:  (1)  general  cargo,  (2)  liquid  bulk  and 
(3)  dry  bulk.  The  last  includes  grain.  Inventory  levels  for  each  commodity 
group  at  each  port  are  reported  in  two  different  sets  of  units: 
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(1)  hundreds  of  tons, 

(2)  number  of  days'  influx. 

The  quantity  in  (2)  is  calculated  as  the  quantity  in  (1)  divided  by  the 
average  daily  influx  rate  of  that  commodity  group  into  that  port  (a 
constant  which  is  supplied  by  the  user). 

Due  to  space  constraints  for  the  printed  report,  certain  abbreviations 
are  used  to  identify  the  different  lines  of  output.  Those  abbreviations 
are  defined  below. 


Abbreviation 

Meaning 

Description 

DR 

"dry  ratio" 

Number  of  days' 

influx  of  dry  bulk. 

LR 

"liquid  ratio" 

Number  of  days' 

influx  of  liquid  bulk. 

GR 

"general  ratio" 

Number  of  days ' 

influx  of  general  cargo 

DT 

"dry  tonnage" 

Hundreds  of  tons 

of  dry  bulk. 

LT 

"liquid  tonnage" 

Hundreds  of  tons 

of  liquid  bulk. 

GT 

"general  tonnage" 

Hundreds  of  tons 

of  general  cargo. 

E.  ERROR  MESSAGES 

This  section  describes  all  error  messages  provided  by  NETSIM  II.  The 
possible  reasons  for  the  generation  of  each  message  and  recommended  user 
action  are  also  discussed. 

The  user  is  cautioned  at  the  outset  that  attempts  to  pinpoint  a  particular 
error  to  selected  input  data  must  be  interpreted  as  answers  to  the  question, 
"Where  should  the  error  search  begin?"  The  real  cause  of  the  trouble  may 
actually  be  elsewhere  and  it  would  behoove  the  user  to  examine  the  complete 
input  data  deck  in  each  error  instance.  The  descriptions  provided  below 
attempt  to  point  at  likely  underlying  error  conditions  wherever  feasible, 
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but  until  all  possible  errors  have  occurred  in  every  possible  way,  no  such 
treatment  can  hope  to  be  exhaustive. 

NETSIM  II's  error  messages  complement  SIMSCRIPT's  own  error  codes 
listed  in  reference  [12].  Such  error  conditions  as  probabilities  not 
summing  to  1  in  frequency  distributions  are  not  checked  for  in  NETSIM  II 
since  SIMSCRIPT  performs  this  function  quite  adequately. 

Finally,  the  user  should  understand  that  a  run  of  NETSIM  II  which  does 
not  produce  any  error  messages  does  not  guarantee  that  the  run  is  correct. 

It  is  possible  for  the  user  to  input  an  erroneous  but  logically  self- 
consistent  data  set,  in  which  case  all  the  sophisticated  error  diagnostics 
imaginable  would  be  of  little  value.  Thus,  the  user  is  encouraged  to 
scrutinize  the  results  of  each  run  for  consistency  and  face  validity. 

The  error  messages  are  described  in  subsections  below,  where  the  title 
of  each  subsection  gives  the  name  of  the  program  unit  where  the  errors 
occurred.  Input  data  mentioned  under  each  error  message  are  given  addresses 
which  give  their  item  numbers  in  Section  C  of  this  manual. 

1.  Routine  Movement  Controller 
- NETSIM  II  ERROR  MESSAGE  4101 - 

VESSEL’S  NEXT. FACILITY  DDDD  DOES  NOT  MATCH  WITH  IDENTIFICATION  NUMBER  OF 
ANY  FACILITY 

This  message  occurs  when  the  identification  nuntoer  of  the  next  facility 
DDDD  through  which  the  vessel  must  travel,  obtained  from  the  FACILITIES. ID. 
TABLE,  does  not  match  the  identification  number  of  any  facility  in  the  system. 
The  error  is  most  likely  to  be  in  the  input  data  for  one  or  all  of  the 
following  items: 


-100- 


(a) 

FACILITIES . ID . TABLE 

(item  C2) 

(b) 

HI. PORT 

(item  A6) 

(c) 

HI. LOCK 

(item  A8) 

<d) 

HI. REACH 

(item  A10) 

(e) 

HI. LAKE 

(item  A12) 

(f) 

SWITCH . FOR . WELLAND 

(item  A14) 

The  user  is  also  referred  to  NETSTM  II* s  numbering  convention  explained 
early  in  this  User  Manual. 


- NETSIM  II  ERROR  MESSAGE  4102 - 

ENTRY  IN  TABLE. OF. NEXT. NODES  (A  ,  B)  EQUAL  TO  CCCC  DOES  NOT  MATCH  WITH 
ROUTE  IDENTIFICATIONS  IN  FIRST  COLUMN  OF  PARALLEL. FACILITIES. TABLE 

The  corrective  action  here  involves  verifying  the  validity  of  the 
entry  CCCC  in  row  A,  column  B  of  the  TABLE. OF. NEXT. NODES  and  matching  this 
entry  with  the  first  column  of  the  PARALLEL. FACILITIES. TABLE.  The  user  is 
urged  to  consult  the  description  for  these  two  tables  as  well  as  the  number¬ 
ing  convention  used  in  NETSIM  II. 

- NETSIM  II  ERROR  MESSAGE  4103 - 

ROW  A  IN  THE  PARALLEL. FACILITIES .TABLE  DOES  NOT  CORRECTLY  MATCH  WITH 
THE  VESSELS'  CURRENT. NODE  BBBB 

This  message  may  be  due  to  an  error  in  row  A  of  the  PARALLEL. FACILITIES. 
TABLE.  The  fifth  through  the  last  element  in  this  row  must  completely 
describe  this  route  in  terms  of  node,  link,  node,  link,  .  .  .  node,  starting 
vith  the  upstream  end  node  of  this  route  and  ending  with  the  downstream  end 
node  of  this  route. 
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The  error  may  also  be  caused  by  Che  fact  that  BBBB  Is  not  a  channel 
choice  node,  i.e.,  the  node  where  the  channel  choice  must  be  made.  This 
error  indicates  a  basic  misinterpretation  of  the  input  data  for  the 
channel  choice  mechanism  in  NETSIM  II.  The  user  should  review  the  relevant 
portions  of  this  publication,  including  the  example  problem,  then  reexamine 
the  entire  input  data  set. 


- NETSIM  II  ERROR  MESSAGE  4104 - 

VESSEL'S  NEXT. FACILITY  IS  LESS  THAN  OR  EQUAL  TO  ZERO.  VERIFY  VESSEL'S 
NEXT. NODE  AAAA  IN  TABLE. OF. NEXT. NODES  (B  ,  C) 

If  AAAA  is  the  correct  entry  and  if  it  is  greater  than  1000,  examine 
the  route  in  the  PARALLEL. FACILITIES. TABLE  with  the  identification  number 
AAAA.  Otherwise,  if  the  entry  is  correct  and  less  than  1000,  examine  the 
FACILITIES . ID. TABLE. 

2.  Routine  Alternative  Selector 

- NETSIM  II  ERROR  MESSAGE  4201 - 

VESSEL  WITH  IDENTIFICATION  NUMBER  AAAA,  LENGTH  BBBB  AND  CURRENT. NODE  CCCC 
IS  TOO  LONG  TO  PASS  THROUGH  LOCKS  IN  THIS  SET. 

This  error  is  rather  self-explanatory.  The  vessel's  CURRENT. NODE  CCCC 
should  identify  the  location  in  the  system  where  this  error  occurred. 
Corrective  action  may  involve  either  deleting  this  vessel  from  the  input 
deck,  changing  its  length  or  modifying  its  itinerary.  The  error  could  also 
be  caused  by  incorrect  data  for  the  locks  (Item  B29). 
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- NETSIM  II  ERROR  MESSAGE  4202 - 

ROUTE  IDENTIFICATION  NUMBERS  IN  PARALLEL. FACILITIES .TABLE  INCORRECTLY 
SUPPLIED 

This  error  results  from  the  fact  that  the  route  identification  number 
in  part  1  of  the  PARALLEL. FACILITIES. TABLE  must  be  equal  to  its  identifica¬ 
tion  number  given  in  part  2  (ETT  functions)  of  the  table. 


- NETSIM  II  ERROR  MESSAGE  4203 - 

LOCK  IDENTIFICATION  NUMBER  GIVEN  IN  ETT  FUNCTIONS  FOR  LOCK  AAAA  IS 
INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the  following: 

(a)  ETT  functions  for  lock  AAAA  (item  B42) 

(b)  Lock  identification  numbers  (item  B26) 

(c)  LOK. PARA. CODE  (item  B30). 

- NETSIM  II  ERROR  MESSAGE  4204 - 

REACH  IDENTIFICATION  NUMBER  GIVEN  IN  ETT  FUNCTIONS  FOR  REACH  BBBB  IS 
INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  ETT  functions  for  reach  BBBB  (item  B25) 

(b)  Reach  identification  number  (item  B17) 

(c)  RCH. PARA. CODE  (item  B20). 

- NETSM  II  ERROR  MESSAGE  4205 - 

PROBABILITIES  IN  COLUMN  3  OF  PARALLEL. FACILITIES. TABLE  INCORRECT 
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3.  Routine  Stochastic  Time  Calculations 


- NETSIM  II  ERROR  MESSAGE  5401 - 

LOCK  IDENTIFICATION  NUMBER  FOR  LOCK  AAAA  GIVEN  IN  THEORETICAL 
FUNCTION  FOR  LONG  ENTRY  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following : 

(a)  Theoretical  function  for  long  entry  (item  B41) 

(b)  Lock  identification  number  (item  B26) 

(c)  CDF. MOVING  (item  B31). 

- NETSIM  II  ERROR  MESSAGE  5402 - 

LOCK  IDENTIFICATION  NUMBER  FOR  LOCK  BBBB  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  SHORT  ENTRY  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  short  entry  (item  B41) 

(b)  Lock  identification  number  (item  B26) 

(c)  CDF. SHORT  (item  B32). 

- NETSIM  II  ERROR  MESSAGE  5403 - 

LOCK  IDENTIFICATION  NUMBER  FOR  LOCK  CCCC  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  CHAMBER  CYCLE  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  chamber  cycle  (item  B41) 


(b)  Lock  identification  number  (item  B26) 

(c)  CDF. CHAMBER  (item  B35). 

- NETSIM  II  ERROR  MESSAGE  5404 - 

LOCK  IDENTIFICATION  NUMBER  FOR  LOCK  DDDD  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  CHAMBER  EXIT  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  chamber  exit  (item  B41) 

(b)  Lock  identification  number  (item  B26) 

(c)  CDF. STERN. CLEAR. TIME  (item  B33) . 

- NETSIM  II  ERROR  MESSAGE  5405 - 

LOCK  IDENTIFICATION  NUMBER  FOR  LOCK  EEEE  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  THROAT  EXIT  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  throat  exit  (item  B41) 

(b)  Lock  identification  number  (item  B26) 

(c)  CDF. GATE. TO. CP. TIME  (item  B34). 

- NETSIM  II  ERROR  MESSAGE  5406 - 

REACH  IDENTIFICATION  NUMBER  FOR  REACH  AAAA  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  REACH  TRANSIT  TIME  IS  INCONSISTENT  WITH  OTHER  DATA 

nils  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  reach  transit  time  (item  B24) 
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(b)  Reach  identification  number  (item  B17) 

(c)  CDF.RTT  (item  B21). 

- NETSIM  II  ERROR  MESSAGE  5407 - 

LAKE  IDENTIFICATION  NUMBER  FOR  LAKE  BBBB  GIVEN  IN  THEORETICAL  FUNCTION 
FOR  LAKE  TRANSIT  TIME  IS  INCONSISTENT  WITH  OTHER  DATA 

This  error  may  be  due  to  incorrect  data  for  one  or  all  of  the 
following: 

(a)  Theoretical  function  for  lake  transit  time  (item  B16) 

(b)  Lake  identification  number  (item  B12) 

(c)  CDF.LTT  (item  B15). 

4.  Routine  Query  Intralake  Travel  Table 

- NETSIM  II  ERROR  MESSAGE  5701 - 

LAKE  NODES  FOR  LAKE  AAAA  GIVEN  IN  INTRALAKE . TRAVEL . TABLE  ARE  INCONSISTENT 
WITH  OTHER  DATA.  IN  PARTICULAR,  CHECK  FIRST  ROW  IN  TABLE 

If  INTRALAKE. TRAVEL. TABLE  is  correct,  check  TABLE. OF. NEXT. NODES  and 
FACILITIES . ID. TABLE . 

- NETSIM  II  ERROR  MESSAGE  5702 - 

LAKE  NODES  FOR  LAKE  BBBB  GIVEN  IN  INTRALAKE. TRAVEL. TABLE  ARE  INCONSISTENT 
WITH  OTHER  DATA.  IN  PARTICULAR,  CHECK  FIRST  COLUMN  IN  TABLE 

If  INTRALAKE. TRAVEL. TABLE  is  correct,  check  TABLE. OF. NEXT. NODES  and 


FACILITIES. ID. TABLE 


- NETSIM  II  ERROR  MESSAGE  5703 - 

LAKE  IDENTIFICATION  NUMBER  FOR  LAKE  CCCC  GIVEN  IN  INTRALAKE . TRAVEL . TABLE 
IS  INCONSISTENT  WITH  OTHER  DATA 

If  INTRALAKE. TRAVEL. TABLE  is  correct,  check  lake  identification 
number  (item  B12). 

5.  Routine  Exit  Queue 

- NETSIM  II  ERROR  MESSAGE  6201 - 

EXIT. QUEUE  EVENT  INVOKED  UNDER  ERROR  CONDITIONS.  VESSEL  ID  AAAA  ; 

LOCK  ID  BBBB  ;  SIMULATION  TIME  CCCCCC. 

This  error  occurs  when  the  chamber  is  empty  but  the  water  level  is 
incorrect  and  the  chamber  is  neither  cycling  nor  scheduled  to  recycle. 

The  error  may  be  difficult  to  trace  since  any  single  incorrect  item  (or 
presence  of  extraneous  data  or  deletion  of  some  data)  in  the  input  data 
deck  can  cause  the  error.  This  manual  can  only  suggest  a  sequential 
series  of  steps  towards  this  objective: 

(a)  Inspect  all  lock  data,  but  particularly  the  locking  time 
distributions. 

(b)  Inspect  TABLE. OF. NEXT. NODES. 

(c)  Inspect  FACILITIES. ID. TABLE  (and  PARALLEL. FACILITIES .TABLE  if 
relevant) . 

(d)  Inspect  complete  input  data  deck. 

(e)  Obtain  event  log  up  to  program  termination  and  trace  simulation 
events. 

(f)  Refer  to  program  maintenance. 
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6.  Routine  Transit  Throat 

- NETSIM  II  ERROR  MESSAGE  6401 - 

TRANSIT  THROAT  EVENT  INVOKED  UNDER  ERROR  CONDITIONS.  VESSEL  ID  AAAA  ; 

LOCK  ID  BBBB  ;  SIMULATION  TIME  CCCCCC. 

This  error  occurs  when  the  water  level  is  incorrect  but  the  chamber 
is  neither  cycling  nor  scheduled  to  recycle.  For  corrective  action,  refer 
to  suggestions  made  above  for  error  message  6201. 

- NETSIM  II  ERROR  MESSAGE  6402 - 

TRANS IT. THROAT  EVENT  EXECUTED  PRIOR  TO  THE  END. CYCLE  EVENT.  VESSEL  ID 
AAAA  ;  LOCK  ID  BBBB  ;  SIMULATION  TIME  CCCCCC. 

The  priority  order  in  NETSIM  II  gives  a  higher  priority  to  the 
END. CYCLE  event  over  the  TRAN SIT. THROAT  event  if  both  are  scheduled  to 
take  place  at  the  same  instant.  For  corrective  action,  refer  to  suggestions 
made  above  for  error  message  6201.  However,  before  referring  to  program 
maintenance,  obtain  source  decks  for  the  preamble  and  the  TRANS IT. THROAT 
routine,  compile  them  to  obtain  new  object  decks  and  rerun  the  simulation. 

7.  Routine  Breeze  Through  Welland 

- NETSIM  II  ERROR  MESSAGE  6701 - 

VESSEL  AAAA  OF  LENGTH  BBBB  IS  TOO  LONG  TO  GO  THROUGH  THE  WELLAND  CANAL 
Corrective  action  for  this  error  may  involve  one  of  the  following 
courses : 

(a)  Delete  vessel  from  Input  data  deck 

(b)  Modify  length  of  vessel 

(c)  Modify  this  routine. 
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A.  INTRODUCTION 


This  appendix  presents  one  form  of  a  sample  problem  that  was  used 
largely  for  testing  the  simulation  package.  In  the  interest  of  reducing 
data  requirements  and  saving  on  computer  run  costs,  it  was  decided  not 
to  use  the  entire  Great  Lakeu-St.  Lawrence  Waterway  System  (GL-SLS). 
Instead,  a  reduced  hypothetical  navigation  system  which  resembles  the 
GL-SLS  in  many  respects  was  chosen.  That  system  is  shown  in  Figure  B-l. 
Figure  B-l  also  includes  the  facility  numbers  which  were  assigned. 

B.  INPUT  DATA 

The  main  input  data  stream  is  displayed,  in  sequence,  in  Figures  B-2 
through  B-8.  Following  are  explanations  of  those  data. 

Figure  B-2  contains  what  may  be  classified  as  run  parameters.  Each 
number  will  be  explained  individually.  Variable  names  are  those  used  in 
the  User  Manual  (Appendix  A). 


000 

SEASON. LENGTH 

This  run  will  simulate  30000 
minutes  (about  21  days). 

0 

EDB . CODE 

This  is  not  an  EDB  run. 

0 

LOOK. AHEAD. CODE 

The  service  look  ahead  feature 
will  not  be  used. 

0 

PARA. CODE 

There  are  no  parallel  route 
options. 

9 

TAPE. DRIVE 

The  event  log  will  be  written 
to  unit  9. 

12 

HI. PORT 

The  highest  numbered  port  is  12. 
This  is  the  "Atlantic  Port." 

12 

N . PORT 

There  are  12  ports. 

15 

HI. LOCK 

The  highest  numbered  lock  is  15. 

Figure  B-l.  Example  Navigation  System 


I 

I 

I 

i 

I 


30000 

9 


3 

N . LOCK 

There  are  3  locks. 

22 

HI. REACH 

The  highest  numbered  reach  is  22. 

7 

N. REACH 

There  are  7  reaches. 

27 

HI. LAKE 

The  highest  numbered  lake  is  27. 

5 

N.LAKE 

There  are  5  lakes. 

0 

SWITCH. FOR. WELLAND 

The  system  contains  no  "Welland." 

23 

NO. OF. NODES 

There  are  23  nodes  in  the  system. 

5 

GEN. INDEX 

Commodity  type  5  is  general  cargo. 

1 

LIQ. INDEX 

Commodity  type  1  is  liquid  bulk. 

2 

GRN . INDEX 

Commodity  type  2  is  grain. 

2 

DRY.LO 

Commodity  types  2  through  4 

4 

DRY. HI 

are  dry  bulk  cargoes . 

12 

ATLANTIC. PORT 

Port  12  represents  the  world 
beyond  the  mouth  of  the  St.  Lawrence 
River.  This  should  always  be  the 
same  as  HI. PORT. 

1 

STREAM 

Random  number  stream  1  will  be  used 
in  a  random  mechanism  involved  with 
choosing  saltwater  vessels'  cargoes. 

2 

STREAM1 

Random  number  stream  2  will  be  used 
for  making  empty  backhaul  decisions. 

3 

STREAM2 

Random  number  stream  3  will  be  used 
to  calculate  the  random  element  of 
time  in  berth. 

0 

G.C. SWITCH 

Saltwater  vessels  are  not  required 
to  change  berths  between  unloading 
and  loading  general  cargo. 

8 

ERIE. EAST 

The  highest  numbered  port  above  the 
Welland  Canal  is  8. 

10 

DR. MAX 

If  more  than  10  days'  influx  of  dry 
bulk  cargo  has  accumulated  at  any 
port,  dry  bulk  vessels  which  are 
dispatched  from  that  port  loaded  will 
be  marked  for  empty  backhaul. 

10 

LR.MAX 

As  in  the  previous  item,  only  for 
liquid  commodities  and  vessels. 
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There  are  5  commodities.  This 
number  should  always  be  the  same 
as  GEN. INDEX. 

COM. ARRIVAL  external  event  notices 
will  be  read  from  unit  7. 

CREAT. VESSEL  external  event  notices 
will  be  read  from  unit  8. 

The  first  vessel  class  ranges  from 
0  to  400  feet  in  length. 

The  second  vessel  class  ranges  from 
410  to  730  feet  in  length.  The 
third  class  is  740  feet  and  over. 

Itineraries  for  saltwater  vessels 
are  read  from  unit  11. 


12 


RAT. UN IT 


The  commodity  inventory  report  will 
be  printed  on  unit  12. 


133.4 

112.0 

93.4 

87.5 

0.95 

1 

80 


LK.2500HP. LESS. ADJ 


LK. 4000HP .OR. LESS .ADJ 


LK . 5000HP . OR . GRT . ADJ 


LK. 8000HP . OR . GRT . ADJ 


VSL.LDG. FACTOR 


MIN.CARG(l) 


MIN.CARG(2) 


Vessels  of  2500  horsepower  or  less 
will  take  33.4 %  longer  to  travel 
between  2  points  on  a  lake  than  will 
vessels  with  4001  through  5000 
horsepower. 

Vessels  between  2501  and  4000 
horsepower  require  12%  longer  for  lake 
travel  than  the  4001  through  5000 
horsepower  class. 

Vessels  between  5001  and  8000 
horsepower  require  only  93.4"  as  long 
for  lake  travel  as  the  4001  through 
5000  horsepower  class. 

Vessels  of  over  8000  horsepower  require] 
only  87.5%  as  long  for  lake  travel  as 
the  4001  through  5000  horsepower  class. 

The  load  limit  for  any  vessel  is  95% 
of  the  stated  capacity.  (The 
capacity  is  stated  in  the  CREAT. VESSEL 
external  event  notice.) 

The  minimum  amount  of  general  cargo 
which  qualifies  for  loading  on  a 
vessel  is  100  tons. 

The  minimum  amount  of  liouid  bulk 
cargo  which  qualifies  for  loading  ontfl 
a  vessel  is  8000  tons.  Note  that  thil 
means  8000  tons  all  bound  for  the  sanM 
destination. 
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80 

MIN.CARG(3) 

As  above,  but  for  dry  bulk 
commodities. 

4 

BER. CONV  (1) 

Commodity  type  1  requires  berth 
type  4  (liquid). 

3 

BER. CONV (2) 

Commodity  type  2  requires  berth 
type  3  (grain) . 

2 

BER.CONV (3) 

Commodity  types  3  and  4  require  berth 

2 

BER. CONV (4) 

type  2  (dry  bulk) . 

1 

BER. CONV (5) 

Commodity  type  5  requires  berth 
type  1  (general  cargo). 

Figure  B-3  contains  all  of  the  port  data.  The  values  for  the  first 
port  (the  first  8  lines  of  data)  will  be  explained.  Successive  sets  of 
data  simply  repeat  the  same  format. 


First  Line: 


1  Port  number  1 


30 

240 

40 


A  minimum  of  30  minutes  is  required  for  a 
vessel  to  enter  and  leave  the  port. 

24000  tons  of  dry  bulk  commodities  arrive 
(overland)  into  port  each  day. 

4000  tons  of  liquid  bulk  arrive  each  day. 


8 


800  tons  of  general  cargo  arrive  each  day. 


27 


The  minimum  depth  of  the  port  is  27  feet. 


1  1  port  is  designated  as  a  "nearby  port,"  at 

which  cargo  may  be  sought  if  none  is  available 
here  (in  port  1). 


Second  Line: 


2 


The  nearby  port  is  port  number  2. 


Third  Line: 


1 


Port  number  1. 


.01 


The  unloading  rate  for  general  cargo  (at  port  1) 
is  l  ton  per  minute. 
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I 

I 

I 


\ 


I 


1 

30 

240 

40 

8 

2 

2.0 

1 

.01 

.14 

1.8 

1 

.01 

.25 

1.8 

2.0 

l 

15 

15 

15 

15 

1 

25 

25 

1 

2 

10 

3 

2 

1 

.95 

.95 

.95 

.95 

.95 

2 

30 

200 

40 

0 

1 

2.0 

2 

.01 

.14 

1.8 

2 

.01 

.25 

1.8 

2.0 

2 

15 

15 

15 

15 

2 

25 

25 

• 

2 

1 

6 

2 

1 

2 

.95 

.95 

.95 

.95 

.95 

3 

40 

200 

120 

40 

4 

3 

.01 

.14 

1.8 

2.0 

3 

.01 

.25 

1.8 

2.0 

3 

15 

15 

15 

15 

3 

25 

25 

3 

10 

6 

3 

2 

3 

.95 

.95 

.95 

.95 

.95 

4 

30 

160 

120 

16 

3 

2.0 

4 

.01 

.14 

1.8 

4 

.01 

.25 

1.8 

2.0 

4 

15 

15 

15 

15 

4 

25 

25 

4 

4 

4 

3 

1 

4 

.95 

.95 

.95 

.95 

.95 

5 

35 

120 

80 

24 

4 

A 

5 

.01 

.14 

1.8 

2.0 

5 

.01 

.25 

1.8 

2.0 

5 

15 

15 

15 

15 

5 

25 

25 

5 

6 

5 

1 

2 

5 

.95 

.95 

.95 

.95 

.95 

6 

25 

160 

120 

16 

5 

7 

6 

.01 

.14 

1.8 

2.0 

6 

.01 

.25 

1.8 

2.0 

6 

15 

15 

15 

15 

6 

25 

25 

6 

6 

5 

1 

2 

6 

.95 

.95 

.95 

.95 

.95 

27  1 


27  1 


27  l 


27  1 


27  2 


27  2 


Figure  B-3. 


Port  Data 
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The  unloading  rate  for  dry  bulk  cargo  is  14 
tons  per  minute. 


Fourth  Line: 


Fifth  Line: 


Sixth  Line: 


Seventh  Line: 


The  unloading  rate  for  grain  is  180  tons  per 
minute . 

The  unloading  rate  for  liquid  cargoes  is  200 
tons  per  minute. 


Loading  rates  for  general  cargo,  dry  bulk, 
grain  and  liquid  in  the  same  format  as  the 
unloading  rates. 


Port  number  1. 

The  mean  random  component  of  turnaround 

time  in  port  is  15  minutes  for  each  of 

the  4  berth  types.  Fifteen  minutes  is  also  the 

standard  deviation  of  this  component. 


Port  number  1. 

If  more  than  25  dry  bulk  vessels  are  awaiting 
cargo  at  this  port,  any  other  dry  bulk  vessel 
that  has  just  completed  unloading  will  be  sent 
back  to  its  origin  empty. 

Same  as  above,  but  for  liquid  bulk  vessels. 


Port  number  1. 


This  port  has  2  general  cargo  berths. 
This  port  has  10  dry  bulk  berths. 

This  port  has  3  grain  berths. 

This  port  has  2  liquid  bulk  berths. 


Eighth  Line : 


Port  number  1. 
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0.95 


Any  bulk  vessel  that 

(1)  has  just  finished  loading  commodity  1,  and 

(2)  has  not  been  marked  for  empty  backhaul  due 
to  cargo  accumulation  in  v,'is  port, 

has  a  .95  probability  of  be^r.-_  arked  for  empty 
backhaul.  If  it  is  so  marked,  it  will  return 
to  this  port  empty  after  unloading  at  its 
destination  port. 

0.95  Same  as  above  for  commodities  2,  3,  4 

0.95  and  5. 

0.95 

0.95 


Figure  B-4  contains  the  lake  data.  The  data  for  the  first  lake 
(first  5  lines)  will  be  explained. 


First  Line: 


23 

3 

0 

1 


ID. LAKE 

NUM. OF. LAKE. NODES 
LAK. PARA. CODE 

CDF.LTT 


Lake  number  23. 

There  are  3  nodes  on  this  lake 

This  lake  is  not  part  of  a 
parallel  route  set. 

The  lake  transit  time  distrib¬ 
ution  is  specified  empirically 


Second  Line: 


23 


Lake  number  23. 


1  The  three  nodes  on  lake  number  23 

2  are  numbered  1,  2  and  13. 

13 


Third  Line: 


1 

0 

400 


Travel  times  from  node  1  are  to  follow. 
Travel  time  from  node  1  to  node  1  is  zero. 


Travel  time  from  node  1  to  node  2  is  400  minutes 
(for  vessel  with  4000-5000  horsepower). 
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23 

23 
1 
2 

13 

24 

24 
15 

4 
3 

25 

25 

15 

5 

16 

26 
26 

17 

6 

7 

8 

18 
27 
27 
20 

9 

21 


3 

0 

l 

2 

0 

400 

*00 

0 

960 

600 

3 

0 

15 

4 

0 

900 

900 

0 

1000 

2*0 

3 

0 

15 

5 

0 

800 

800 

0 

920 

200 

5 

0 

17 

6 

0 

180 

180 

0 

600 

**0 

800 

6*0 

8*0 

700 

3 

0 

20 

9 

0 

180 

180 

0 

180 

600 

l 

13 

960 

600 

0 

1 

3 

1000 

240 

0 

1 

16 
920 
2  00 
0 
1 

7  8 


600 

800 

*40 

6*0 

0 

*00 

400 

0 

*60 

1*0 

1 

21 

700 

600 

0 


18 

8*0 

700 

*60 

1*0 

0 


Figure  B-4.  Lake  Data 


120' 


960 


i 
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Fourth  Line: 
2 

400 

0 

600 


Fifth  Line: 


Travel  time  from  node  1  to  node  13  is  960  minutes. 


Travel  times  from  node  2  are  to 
Travel  time  fron  node  2  to  node 
Travel  time  from  node  2  to  node 
Travel  time  from  node  2  to  node 


follow. 

1  is  400  minutes. 

2  is  zero. 

13  is  600  minutes. 


As  above,  travel  times  from  node  13  to  other  nodes. 


The  remaining  data  in  Figure  B-4  are  in  the  above  format,  for  lakes  24, 
25,  26  and  27. 

Figure  B-5  contains  the  reach  data.  The  first  three  lines  are  for 
reach  number  16. 


First  Line: 


16 

20 

1 

0 

0 


14 

15 


ID. REACH 
LENGTH 
PASS. RULE 
RCH. PARA. CODE 

CDF.RTT 

UPSTREAM. NODE 

DOWNSTREAM. NODE 
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Reach  number  16. 

This  reach  is  20  miles  long. 

Passing  is  allowed. 

This  reach  is  not  part  of  a 
parallel  route  set. 

A  theoretical  function  will  be 
used  to  calculate  reach  transit 
time. 

Node  14  is  the  upstream  node  of 
this  reach. 

Node  15  is  the  downstream  node  of 
this  reach. 
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Figure  B-5.  Reach  Data 
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A 


Second  Line: 


Theoretical  distribution  parameters  for  downstream 
travel  time  through  reach  16  are  to  follow. 


16 


10 


Uniform  distribution. 


50 

80 


Travel  times  will  be  chosen  from  a  uniform 
distribution  between  50  and  80  minutes. 


Third  Line: 


Use  random  number  stream  4  for  this  sampling. 


16 


Theoretical  distribution  parameters  for  upstream 
travel  time  through  reach  16  are  to  follow. 


10 


Uniform  distribution. 


60 

90 


Travel  times  will  be  chosen  from  a  uniform 
distribution  between  60  and  90  minutes. 


Use  random  number  stream  4  for  this  sampling. 


The  remainder  of  Figure  B-5  is  data  for  reaches  17  through  22  in  the  same 
format. 

Figure  B-6  contains  the  lock  data.  The  first  six  lines  are  for  lock 
number  13. 


First  Line: 

Lock  number  13. 

The  upstream  node  of  this  lock  ■'s 
node  number  13. 

The  downstream  node  of  this  lock 
is  node  number  14. 

120  MAXIMUM. VESSEL. LENGTH  Vessels  over  1200  feet  in  length 

cannot  pass  through  this  lock. 

0  LOK. PARA. CODE  This  lock  is  not  part  of  a  parallel 

route  set. 

0  CDF.MOVING  A  theoretical  distribution  function 

will  be  used  for  long  entry  time. 


13  ID. LOCK 

13  UP. DIR. NODE 

14  DN. DIR. NODE 
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Figure  B-6.  Lock  Data 
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CDF. SHORT 

CDF. STERN. CLEAR. TIME 
CDF . GATE . TO . CP . T IME 
CDF. CHAMBER 


Each  of  the  4  remaining  segments 
of  locking  time  will  have  a 
theoretical  distribution. 


MOVING. ADJUSTMENT 


Class  1  vessels  (under  400  feet) 
require  10%  less  time  for  a  moving 
entry  than  do  class  2  vessels. 
Class  3  vessels  require  10%  longer 
than  class  2. 


SHORT. ADJUSTMENT 


STERN . CLEAR . AD JUSTMENT 
GATE . TO . CP . ADJUSTMENT 
CHAMBER. ADJUSTMENT 


Class  1  and  class  3  vessels  require 
15%  less  and  157  more  time, 
respectively,  than  class  2  vessels 
for  a  short  entry. 

Similarly  for  chamber  exit, 
throat  exit  and  chamber 
cycle  times. 


Second  Line: 


Lock  number  13. 


Third  through  Sixth  Lines: 


Normal  distribution  will  be  used  for  long  entry  time.] 


The  mean  of  the  normal  distribution  is  20  minutes. 

The  standard  deviation  of  the  normal  distribution 
is  5  minutes. 

Random  sampling  from  this  distribution  will  be 
done  with  random  number  stream  4. 


Theoretical  distribution  parameters,  in  above 
format,  for  short  entry,  chamber  cycle,  chamber 
exit  and  throat  exit  times. 


The  seventh  through  eighteenth  lines  in  Figure  B-6  are  for 
locks  14  and  15.  The  nineteenth  (last)  line  contains  four  parameters 
that  apply  to  all  of  the  locks. 


Nineteenth  Line: 


15  STAT. ADDITIVE 


60  ARR. SENTRY . PROPORTION 


10  QUE . SENTRY . ADDITIVE 


15  PROCESS .ADDITIVE 


Long  entry  from  a  stationary  point 
in  a  queue  requires  15%  longer  than 
a  moving  long  entry. 

Time  required  to  move  from  the  clear 
point  to  a  short  entry  position  is 
60%  of  total  (moving)  long  entry  time. 

Time  required  to  move  to  a  short  entry 
position  requires  10%  longer  if  the 
movement  begins  from  a  stationary  point 
in  a  queue. 

Chamber  cycle  time  is  15%  longer  when 
the  chamber  is  occupied  than  when  it 
is  empty. 


Figure  B-7  contains  the  table  of  next  nodes.  Note  that  the  columns 
correspond  to  the  port  numbers,  1  through  12,  and  the  rows  correspond  to 
the  node  numbers,  1  through  23  (the  first  12  of  which  are  ports),  although 
these  column  and  row  labels  have  not  been  punched  explicitly. 

Consider,  for  example,  the  fourth  row  in  the  table.  The  first  entry 
is  a  15,  indicating  that  in  going  from  node  4  to  node  1,  the  next  node 
encountered  is  node  15.  The  user  should  verify  this  on  the  navigation 
system  diagram  (Figure  B-l).  The  third  entry  in  the  fourth  row  is  a  3, 
indicating  that  in  going  from  node  4  to  node  3  the  next  node  is  node  3; 
in  other  words  there  are  no  intermediate  nodes.  The  fourth  number  in  the 
fourth  row  is  a  zero;  going  from  node  4  to  node  4  is  meaningless. 

Figure  B-8  contains  the  facilities  Id  table.  Note  that  this  is  a 
lower  half  matrix  without  the  main  diagonal.  Hence  the  rows  correspond  to 
nodes  2  through  23  and  the  columns  correspond  to  nodes  1  through  22.  The 
first  entry  in  the  table,  23,  indicates  that  in  going  from  node  2  to  node  1 
the  next  facility  is  23.  The  sixth  (last)  number  in  the  sixth  row  is  a  26. 
This  indicates  that  in  going  from  node  7  to  node  6  (or  vice  versa)  the 
next  facility  is  number  26.  The  muJ  titude  of  zeroes  in  the  table  are  for 
pairs  of  nodes  that  are  not  consecutive. 
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This  appendix  has  presented  an  example  of  a  main  input  data  stream. 

A  run  of  NETSIM  II  also  requires  (1)  saltwater  vessel  itineraries,  (2) 

CREAT. VESSEL  external  event  notices  and  (3)  COM. ARRIVAL  external  event 
notices  on  separate  input  files.  Part  III  of  this  report  documents  three 
support  programs  which  have  been  provided  to  facilitate  preparation  of 
these  three  kinds  of  inputs.  The  complete  data  streams  on  these  three  files 
are  too  voluminous  to  be  reproduced  here.  Sample  records,  however,  are 
shown  in  Figure  B-9. 

Figure  B-9 (a)  shows  a  sample  saltwater  vessel  itinerary  record.  Note 
that  this  particular  record  consists  of  two  cards.  The  first  number,  6, 
indicates  that  there  are  six  stops  on  the  itinerary.  The  order  of  the  ports 
of  call  is  7,  3,  9,  10,  11,  12.  The  last  number,  12,  is  the  "Atlantic  Port" 
at  which  the  vessel  will  leave  the  system.  On  this  itinerary  the  vessel 
will  unload  30%  of  its  cargo  at  port  7  and  then  load  cargo  amounting  to 
25%  of  its  capacity  before  leaving  port  7.  At  port  9  it  will  unload  13.3% 
and  load  16.7%,  and  so  on. 

Figure  B-9(b)  is  a  sample  CREAT. VESSEL  external  event  notice.  The 
numbers  are  interpreted  as  follows: 


7200 

The  vessel  is  to  be  introduced 
system  at  simulation  time  7200. 

into 

the 

12 

The  vessel  is  to  be  introduced 
(the  Atlantic  Port). 

into 

port  12 

50 

Vessel  length  is  500  feet. 

50 

The  vessel  has  5000  horsepower. 

150 

Vessel  cargo  capacity  is  15000 

tons , 

0 

Not  a  self-unloader. 

20 

Loaded  draft  is  20  feet. 

1 


Vessel  type  1  (saltwater). 


6  7  0.250  0.300  3  0.250  0.300  9  0.167  0.133  10  0.167  0.133 
11  0.167  0.133  12  0.0  0.0 


(a)  Saltwater  vessel  itinerary  record. 


CREAT. VESSEL  7200.  12  50  50  150  0  20  1  0  00  0  104 


(b)  CHEAT. VESSEL  external  event  notice. 


COM. ARRIVAL 

1  1  3  16 

(c)  First  two  cards  of  a  COM. ARRIVAL  event  notice. 


Figure  B-9.  Sample  External  Event 
Notice  Records 
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0  Empty  backhaul  code  (of  little  interest  to 

the  user). 

0  Cargo  tonnage.  NETSIM  II  uses  this  parameter 

to  keep  track  of  the  amount  of  cargo  currently 
being  carried. 

0  Cargo  type.  NETSIM  II  will  adjust  this 

parameter.  The  user  can  leave  it  at  zero. 

0  Vessel  origin.  Again,  this  parameter  is 

adjusted  by  NETSIM  II  as  needed. 

104  Vessel  number  104. 


Figure  B-9(c)  contains  the  first  two  cards  of  a  COM. ARRIVAL  external 
event  notice.  Beginning  on  the  second  card: 

1  This  item  of  cargo  will  originate  in  port  1. 

1  This  cargo  is  commodity  type  1. 

3  The  destination  of  the  cargo  is  port  3. 

16  The  amount  of  commodity  is  1600  tons. 

Many  cards  in  this  same  format  would  be  included  in  a  single 
COM. ARRIVAL  notice.  One  card  is  required  for  each  origin-commodity- 


destination  combination 


CHAPTER  6.  INTRODUCTION  TO  PROSIM 


The  Pennsylvania  Transportation  and  Traffic  Safety  Center  has 

developed  a  computer  simulation  package  for  the  analysis  of  the  Great 

Lakes-St.  Lawrence  Waterway  System^.  This  simulation  package  is  composed 

2 

of  three  parts.  The  first  section  is  the  simulation  program  (NETSIM  II)  , 

which  produces  as  output  an  event  log  describing  each  event  that  occurred 

during  the  simulation.  This  event  log  is  then  processed  by  a  report 

generation  program  (PROSIM).  The  third  part  consists  of  four  support 

programs  which  perform  auxiliary  functions  such  as  specific  data  prepara- 
3 

tions  for  NETSIM  II  .  This  chapter  describes  key  features  of  the  PROSIM 
program  and  succeeding  chapters  delve  into  its  input,  operations  and  output 
capabilities.  A  PROSIM  User  Manual  is  also  provided  in  Appendix  C. 

A.  PROSIM  OBJECTIVES 

The  primary  purpose  of  PROSIM  is  to  remove  the  statistical  output 
generation  burden  from  NETSIM  II.  Main  features  dictating  the  separation 
of  statistical  processing  from  the  actual  simulation  program  were: 

1.  the  critical  need  to  reduce  space  requirements  for 
the  simulation  program; 

2.  ease  of  debugging  and  error  detection; 


^Volume  3  in  this  series  describes  the  rationale  for  and  the  background 
behind  this  model  development  effort. 

2 

The  NETSIM  II  program  is  treated  in  Part  I  of  this  publication. 

3 

The  support  programs  are  documented  in  Part  III  of  this  publication. 
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3.  the  ability  to  tailor  the  output  to  fill  the  needs 
of  the  user  without  conducting  several  reruns  of  the 
time-consuming  simulation  phase;  and 

4.  the  creation  of  a  permanent,  detailed  record  of  the 
simulation  for  calibration  and  operation  analysis 
apart  from  the  aggregate  statistical  reports. 

These  desirable  features  were  not  obtained  without  some  sacrifice  in  time 
requirements.  Clearly,  some  duplicative  effort  exists  between  NETSIM  II 
and  PROSIM  with  regard  to  input-output  processing  'nd  program  structure. 
Nevertheless,  the  flexibility  afforded  by  the  separation  of  statistical 
processing  from  the  simulation  phase  is  deemed  to  be  of  sufficient  merit 
to  warrant  this  structure. 

B.  THE  PROSIM  PROGRAM 

The  PROSIM  program  requires  two  classes  of  input  data: 

(1)  run  parameters 

(2)  NETSIM  II  event  log. 

Chapter  7  elaborates  on  these  data  items. 

The  main  operations  carried  out  by  the  PROSIM  program  are  interpreta¬ 
tion  of  the  event  log  and  the  collection  of  the  relevant  statistical  data 
for  generating  the  output  tables.  In  all,  PROSIM  produces  15  tables  of 
performance  summaries  for  the  fixed  facilities  in  the  system.  The  follow¬ 
ing  list  summarizes  the  contents  of  these  tables: 

(1)  the  number  of  ships  originating  and  terminating  at  each 
port  by  type  as  well  as  the  tonnage,  loading  and  unload¬ 
ing  times,  berth  delays,  cargo  delays  and  queue  lengths 
by  cargo  type; 


-134- 


(2)  at  each  lock  in  the  simulated  system,  the  total  vessels 
processed,  tonnage,  delays,  transit  times,  queue  lengths 
and  utilization  rates  by  direction  and  vessel  type; 

(3)  traffic  summaries  and  transit  times  for  reaches  and  lakes. 

These  output  tables  can  be  printed  both  at  intervals  and  at  the  end  of  the 
simulation.  In  addition  to  these  printouts,  PROSIM  can  also  punch  selected 
statistics  for  further  tests  of  statistical  inference. 

C.  PROGRAM  CAPABILITIES 

PROSIM  currently  exists  as  a  set  of  subroutines  written  in  SIMSCRIPT  II. 5 
for  the  IBM  370/165  computer.  Space  requirements  for  this  program  are  out¬ 
lined  in  Appendix  D.  A  modular  design  was  used  in  constructing  the  program, 
thus  modifications  to  effect  further  statistical  refinement  or  generate 
additional  output  such  as  histograms,  time  flow  charts,  etc.,  would  be 
relatively  simple  to  implement. 
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CHAPTER  7.  INPUT 


This  chapter  describes  and  discusses  the  input  data  required  by 
PROSIM.  Detailed  card  format  specifications  may  be  found  in  Appendix  C, 
PROSIM  User  Manual. 

PROSIM  requires  2  classes  of  input  data: 

(1)  Run  parameters; 

(2)  NETSIM  II  event  log. 

Each  of  these  classes  is  treated  in  the  following  sections. 

A.  RUN  PARAMETERS 

This  class  of  data  includes  the  following  items: 

(1)  system  size  parameters 

(2)  total  simulation  run  time  in  minutes 

(3)  length  of  warm-up  periods  in  minutes 

(4)  intermediate  printout  interval  in  minutes 

(5)  input /output  devices 

(6)  selection  of  the  output  tables  to  be  generated 

(7)  vessel  classification  parameters. 

Item  1  includes  specification  of  the  number  of  entities  in  the  system 
(ports,  locks,  vessels,  etc.)  and  pointers  to  the  numbering  scheme  for 
these  entities.  These  data  allow  PROSIM  to  construct  its  entity  structures. 

Item  2  controls  the  total  simulation  run  time  and  must  be  large  enough 
to  provide  the  user  with  a  steady  state  simulation  for  the  desired  period. 
Thus,  if  it  is  desired  to  simulate  a  period  of  30  days  with  a  warm-up  time 
of  4  days,  the  simulation  run  time  T  should  be  set  at 

T  -  1440  x  34 
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where  the  warm-up  time  has  been  added  to  the  desired  simulation  period. 

Item  3  specifies  two  warm-up  periods,  one  for  ports  and  the  other 
for  the  rest  of  the  fixed  facilities  such  as  locks,  reaches,  lakes,  etc. 

The  reason  for  this  dichotomy  is  that  locks  and  reaches  start  the  simula¬ 
tion  in  an  empty  period  whereas  ports  do  not.  Although  two  separate 
warm-up  periods  are  allowed,  they  should  be  set  to  the  same  value  (for 
ease  of  output  interpretation)  until  and  unless  experience  dictates  other¬ 
wise.  If  they  have  different  values,  the  larger  value  should  be  used  in 
the  calculation  of  the  total  run  time  above. 

Item  4  provides  the  interval  between  intermediate  printouts.  The  first 
intermediate  output  is  printed  at  a  simulation  time  equal  to  the  warm-up 
time  plus  the  interval  time.  Subsequent  outputs  are  generated  at  succeed¬ 
ing  intervals  until  the  simulation  time  equals  the  total  run  time  at  which 
point  the  final  output  is  printed.  A  run  with  an  interval  of  10,000  minutes, 
warm-up  time  of  5,000  minutes  and  a  total  run  time  of  40,000  minutes  will 
generate  output  at  the  following  times : 


Time 

15,000  min. 
25,000 
35,000 
40,000 


If  intermediate  output  is  not  desired,  the  interval  value  should  be  set 
equal  to  the  total  run  time. 

Items  5  and  6  specif/  input/output  devices  and  output  options.  The 
output  options  dictate  which  of  PROSIM's  15  tables  are  to  be  printed 
during  intermediate  printouts.  All  of  the  output  tables  are  printed  at 
the  end  of  the  simulation,  however. 


\ 
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Item  7  provides  length  limits  for  determining  vessel  categories. 

As  in  NETSIM  II,  PROSIM  allows  up  to  three  vessel  categories. 

B.  NETSIM  II  EVENT  LOG 

The  NETSIM  II  event  log  is  the  primary  output  of  NETSIM  II  and  the 
main  input  into  PROSIM.  The  event  log  is  a  description  of  all  events 
that  occurred  during  the  simulation  and  lists  the  time  of  occurrence, 
vessel  identification,  vessel  attributes  such  as  length,  current  node,  next 
node,  cargo  tonnage,  commodity  type  and  classification,  facility  identifica¬ 
tion  and  an  event  code^"  which  specifies  the  nature  of  the  event.  The  event 
log  will  normally  be  input  to  PROSIM  through  an  auxiliary  unit  such  as  a 
tape  file  for  ease  of  handling. 


complete  des  ?tion  and  interpretation  of  the  event  codes  is  given 
in  Appendix  A,  .e  I  of  this  publication. 
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CHAPTER  8.  OPERATIONS 


A.  OVERVIEW 

The  conceptual  design  of  PROSIM  is  rather  straightforward  since  its 
main  function  is  merely  to  access  the  NETSIM  II  event  log  and  gather 
relevant  statistics  for  output  printouts.  To  facilitate  this  function, 
PROSIM's  entity  structure  has  been  constructed  very  similarly  to  that  of 
NETSIM  II.  There  are  two  main  differences,  however: 

(1)  Many  entity  attributes,  variables  and  arrays  in 
NETSIM  II  are  not  needed  in  PROSIM.  Instead,  PROSIM 
is  saturated  with  statistic-gathering  SIMSCRIPT 
statements  which  provide  it  automatically  with 
routines  to  calculate  such  parameters  as  the  mean, 
sum  and  standard  deviation. 

(2)  PROSIM  does  not  contain  any  set  structures,  hence 
does  not  contain  owner-member  relationships.  This  is 
because  PROSIM  does  not  conduct  any  vessel  processing 
(as  does  NETSIM  II)  but  simply  gathers  information 
from  the  event  log. 


B.  PROGRAM  STRUCTURE 

PROSIM  begins  event  log  processing  by  referencing  the  initialization 
routine  which  reads  all  the  input  data  and  constructs  PROSIM's  entity 
structures.  Upon  completion  of  its  task,  the  initialization  routine  is 
released  to  conserve  space. 
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PROSIM  next  references  the  event  log  processor  routine  which  controls 
the  program  flow.  Its  main  function  is  to  read  and  interpret  the  event 
log  and  invoke  the  appropriate  support  routines  to  extract  the  necessary 
information  for  generating  user  specified  output  tables.  Upon  reading  the 
event  log,  the  routine  identifies  the  vessel,  the  service  facility  and  the 
nature  of  the  simulation  event.  Appropriate  subroutines  are  called  to 
process  particular  sets  of  data.  Figure  8-1  shows  a  schematic  diagram 
of  this  program  flow.  Upon  completion  of  data  processing,  the  event  log 
processor  routine  resumes  control  to  read  the  next  record  on  the  event 
log  and  repeat  the  cycle.  At  user  specified  intervals  and  at  the  end  of 
the  event  log  data,  printout  routines  are  invoked  to  generate  the  requisite 
output  tables. 

PROSIM  does  not  gather  statistics  during  the  warm-up  period,  the 
length  of  which  is  user  specified,  although  normal  data  processing  opera¬ 
tions  are  carried  out.  That  is,  during  the  warm-up,  simulation  events  as 
described  by  the  event  log  are  noted  and  recorded  but  statistics  are  not 
tabulated. 

The  ports  require  a  different  warm-up  period  from  that  of  the  other 
fixed  facilities  in  PROSIM  because  they  undergo  a  different  transient  state. 

At  the  start  of  the  simulation,  ports  are  initialized  (perhaps  even  saturated) 
with  commodity  arrivals  and  vessel  introductions  and  a  finite  amount  of 
time  may  be  necessary  to  come  down  to  a  "normal"  level  of  traffic^.  Locks 


It  is  also  likely  that  ports  start  out  with  "less  than  normal"  traffic. 
A  separate  warm-up  time  for  ports  is  equally  useful  in  either  case, 
however,  the  user  must  be  cautious  in  interpreting  the  output  if  two 
different  warm-up  periods  are  indeed  specified.  In  such  a  case,  for 
example,  tonnage  flows  into  ports  may  not  be  indicative  of  the  tonnage 
traffic  through  other  facilities. 
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and  reaches,  on  the  other  hand,  start  out  in  an  empty  condition  (i.e., 
without  traffic)  and  a  warm-up  period  is  necessary  for  sufficient 

2 

congestion  to  build  up  so  that  atypical  observations  are  not  recorded. 


^This  discussion  assumes  that  the  user  is  interested  in  the  steady-state, 
rather  than  the  transient,  behavior  of  the  waterway  system. 
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CHAPTER  9 .  OUTPUT 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  describe  in  detail  the  form  of 
and  the  calculations  made  for  the  PROSIM  program  output.  The  output 
consists  of  15  different  tables,  each  of  which  will  be  described 
individually. 

PROSIM  provides  statistical  output  in  three  forms.  These  three  forms 
are:  (1)  generation  of  all  output  tables  at  the  end  of  the  run;  (2) 

generation  of  all  or  selected  output  tables  at  user  specified  intervals 
during  the  run;  and  (3)  punching  selected  statistics  for  further  tests  of 
statistical  inference  at  user  specified  intervals.  PROSIM  also  prefaces 
these  output  forms  with  a  description  of  the  waterway  system  being  anaylzed 
and  other  items  which  may  aid  the  user  in  interpreting  the  values  presented 
in  output  tables. 

PROSIM  provides  performance  summaries  for  each  category  of  system 
facilities.  The  exact  breakdown  of  the  output  form  is  as  follows: 

Locks  -  Tables  1  through  7 

Ports  -  Tables  8  through  12 

Reaches  -  Table  13 

Lakes  -  Table  14 

NETSIM  II's  representation  of  the  Welland  Canal  -  Table  15. 

Data  in  these  tables  may  either  be  accumulated  output  or  calculated 
output.  Accumulated  output  is  simply  that  which  is  tabulated  as  each 
occurence  takes  place  within  the  simulation.  For  example,  total  delay 
is  simply  the  accumulated  value  for  delays  experienced  by  all  vessels. 
Calculated  output  is  that  which  results  through  some  combination  of 
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accumulated  data  within  the  program  itself.  For  instance,  lock  utiliza¬ 
tion  is  a  statistic  which  is  found  by  taking  total  lock  processing  time 
(an  accumulated  value)  as  a  percent  of  total  available  time  for  processing 
(an  input  value — usually  the  simulation  length). 

In  the  intermediate  output  form,  PROSIM  can  produce  selected  output 
displays  if  desired,  rather  than  all  fifteen  output  tables.  This  selection 
capability  allows  generation  of  less  interval  output,  hence  speeding  up  the 
program  by  reducing  expensive  computer  operating  time.  An  instance  where 
all  output  might  not  be  desired  is  the  situation  in  which  emphasis  was 
placed  on  only  a  specific  set  of  variables  (e.g.,  locking  operations  only) 
as  opposed  to  the  complete  simulation  results.  It  should  be  noted  that 
the  final  output  form  always  produces  a  complete  set  of  output  tables, 
regardless  of  which  tables  (if  any)  have  been  suppressed  in  the  intermediate 
output  form.  In  any  case,  the  user  can,  through  intermediate  output, 
increase  the  sample  size  for  his  analysis  without  conducting  many  separate 
entire  simulations. 

The  use  of  intermediate  output,  however,  involves  an  implicit  assump¬ 
tion  about  the  independence  of  the  data.  That  is,  proper  application  of 
many  statistical  methods  requires  that  the  data  used  in  the  analysis  be 
independent.  Observations  on  a  random  variable  generated  at  successive 
points  in  time  in  a  simulation  experiment,  however,  are  generally  auto- 
correlated;  treating  them  as  independent  underestimates  the  variance  of 
the  corresponding  sample  mean.  This  problem  can  be  avoided  by  taking 
observations  at  widely  spaced  intervals,  at  the  expense  of  a  considerable 
loss  of  statistical  power  or  by  data  transformation  which  unfortunately  is 
Inappropriate  in  many  situations.  An  alternative  approach  involves  the 
use  of  spectral  analysis  to  measure  the  degree  of  autocorrelation  and  take 
it  into  account  in  subsequent  tests  of  inference.  This  approach  has  been 
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documented  elsewhere  [13];  no  description  is  given  here.  The  use  of  this 
approach  requires  periodic  observations  on  random  variables  of  interest 
(for  example,  delays).  Therefore,  the  third  output  form  in  PROSIM  pro¬ 
vides  punched  data  on  selected  variables  to  be  used  as  input  into  sub¬ 
sequent  tests  of  spectral  analysis  and  statistical  inference. 

In  summary,  the  primary  output  of  PROSIM  is  the  performance  summary 
for  each  category  of  waterway  facilities  represented  in  the  simulation. 


B.  TABLE  1 

Table  1  presents  summary  statistics  on  a  directional  basis  for  vessels 
processed  at  each  lock  (see  Figure  9-1).  The  format  for  this  table  con¬ 
sists  of  the  statistic  name  in  the  left-hand  column  and  the  name  of  each 
lock  at  the  top  of  the  column. 

The  first  three  figures  are  "total  tonnage"  statistics  given  by  type 
of  cargo.  Overseas  cargo  is  all  cargo  transported  by  saltwater  vessels, 
dry  bulk  cargo  is  that  transported  by  dry  bulk  vessels  and  liquid  bulk 
cargo  is  cargo  transported  by  tankers.  The  total  tonnage  data  are 
accumulated  statistics  developed  by  adding  the  total  tonnage  of  the  vessel 
just  processed  to  all  previously  processed  tonnage.  As  such,  these 
statistics  do  not  include  the  tonnage  data  for  vessels  awaiting  service; 
they  include  data  for  only  those  vessels  which  were  completely  serviced 
at  a  lock. 

The  fourth  statistic  is  the  "utilization  rate"  statistic  given  in 
percent.  This  is  a  calculated  statistic  found  by 

l  l  TTdt  -  DTdt  x  100 
(C  -  W) 
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where 


Tl  -  Total  transit  time  for  vessel  of  classification  type  t  in 
direction  d 

DTdt  =  Total  delay  time  for  vessel  of  classification  type  t  in 
direction  d 

C  =  Current  clock  time 

W  =  Specified  warm-up  period. 

The  numerator  in  this  calculation,  i.e.,  the  difference  between  transit 
time  and  delay  time,  is  the  processing  time  for  vessels  at  a  lock. 

The  final  two  statistics  in  Table  1  represent  the  "current  queue 
length"  and  the  "maximum  queue  length"  at  each  lock.  These  are  both 
accumulated  during  the  simulation  length.  The  current  queue  length  is 
simply  the  number  of  vessels  awaiting  service  at  the  time  of  the  printout. 
This  value  includes  only  those  vessels  waiting  because  the  lock  is  committed 
to  another  vessel  and  does  not  include  the  vessel  being  serviced. 

The  maximum  queue  length  is  found  by  comparing  the  current  queue  length 
with  the  maximum  queue  length  that  has  occurred  thus  far  during  the  simula¬ 
tion  period.  If  the  current  queue  is  greater  than  any  previous  maximum 
length,  then  the  maximum  queue  value  is  changed  to  the  current  queue  length. 
The  magnitude  of  this  statistic  is  of  concern,  since  large  values^-  would 
indicate  the  possibility  of  an  infinite  queuing  situation. 

C.  TABLE  2 

2 

Table  2  presents  four  statistics  for  vessels  of  class  1  processed  at 
each  lock.  All  four  statistics  are  given  on  a  directional  basis  (see 


The  criteria  for  "large  values"  must  be  determined  through  experiment. 

Vessel  categories  are  determined  by  comparing  the  vessel  attributes  with 
user  supplied  category  parameters. 
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Figure  9-2)  and  are  described  below. 


"No.  of  delayed  ships"  represents  accumulated  totals  of  vessels 

delayed  at  each  specified  lock.  "Average  delay"  is  a  calculated  statistic 

3 

derived  in  the  following  manner  : 


i  =  1 
Vd 

where 

*»  Total  delay  time  for  vessel  i  in  direction  d 

V,  =  Total  number  of  delayed  vessels  in  direction  d. 
d 

The  "std  error  for  delay"  is  also  a  calculated  statistic  derived  by  using 

4 

the  standard  deviation  formula  . 


Did2  -  <5d2V 


i  =  1 


Vd-  1 


where 


=»  Delay  time  for  vessel  i  in  direction  d 
Dj  =  Average  delay  for  vessels  delayed  in  direction  d 
=  Total  number  of  delayed  vessels  in  direction  d. 


JThis  formula  will  be  referenced  by  "AvgCX^)"  in  future  text,  where 
is  an  individual  value  for  statistic  X. 

4  _ 

This  formula  will  be  referenced  herein  by  "S.D(X,  X^)"  where  X  is  the 
average  value  for  statistic  X,  and  X^  is  the  corresponding  individual  value. 


1 


1 
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TABLE  2  PERFORMANCE  DETAILS  FOR  LOCKS 


The  "total  delay  time"  value  is  accumulated  during  the  simulation. 

It  represents  the  total  amount  of  delay  incurred  at  a  lock  by  all  vessels 
passing  that  lock  and  thus  includes  delays  in  both  a  stationary  position 
at  queue  as  well  as  at  the  short  entry  position  outside  chamber  gates. 

Delay  in  this  instance  is  defined  as  that  time  spent  at  a  lock  awaiting 
service  and  does  not  include  the  actual  lock  service  (processing)  time. 

It  is  important  to  note  that  all  the  values  printed  in  Table  2  pertain 
to  vessels  delayed  at  a  lock  and  not  for  all  vessels  passing  through  the 
lock.  Thus,  if  the  user  desires  to  obtain  average  delay  for  all  vessels 
obtaining  lock  service,  the  total  delay  time  statistic  must  be  divided  by 
the  total  number  of  ships  statistic  given  in  Table  3. 

D.  TABLE  3 

Table  3  presents  four  additional  statistics  for  all  vessels  of  class  1 
processed  at  each  lock.  All  four  statistics  are  given  on  a  directional 
basis  (see  Figure  9-3)  and  are  described  below. 

"No.  of  total  ships"  is  the  accumulated  total  of  all  vessels  of  class  1 
category  passing  through  each  lock.  This  includes  both  delayed  vessels 
and  zero-delayed  vessels.  "Average  transit  time"  is  a  calculated  statistic 
computed  as  the 

Avg  (TTid) 

where  TT^d  is  the  transit  time  for  vessel  i  traveling  in  direction  d. 

Transit  time  here  is  defined  as  the  sum  of  any  delay  experienced  by  a 
vessel  and  its  lock  processing  time.  Therefore,  if  the  lock  service  time 
is  a  constant,  it  could  be  subtracted  from  the  average  transit  time  to 
derive  the  average  delay  time  for  all  vessels  of  class  1. 
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TABLE  3  PERFORMANCE  DETAILS  FOR  LOCKS 


The  "total  transit  time"  is  an  accumulated  statistic  found  by  summing 
the  time  spent  by  each  vessel  waiting  and  processing  at  a  lock.  The  "std 
error  for  transit"  is  the  standard  deviation  of  the  transit  time  for  each 
vessel  and  is  computed  as  the 

S.D  <Td  ,  Tld> 

where  T^  is  the  average  transit  time  and  T^  is  the  transit  time  for 
vessel  i  in  direction  d. 

E.  TABLE  4 

Table  4  is  very  similar  to  Table  2,  however,  the  statistics  given 
are  for  Class  2  vessels.  All  statistics  are  computed  in  exactly  the  same 
manner  as  for  Table  2. 

F.  TABLE  5 

Table  5  is  similar  to  Table  3,  however,  the  transit  information  given 
pertains  to  vessels  of  Class  2.  All  statistics  are  computed  exactly  as 
previously  described. 

G.  TABLE  6 

Table  6  is  similar  to  Tables  2  and  4,  however,  the  delay  statistics 
given  are  for  Class  3  vessels. 

H.  TABLE  7 

Table  7  is  similar  to  Tables  3  and  5,  however,  the  transit  data  given 
pertain  to  vessels  of  Class  3. 
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I.  TABLE  8 

Table  8  supplies  tonnage  statistics  for  all  vessels  processed  at  each 
port  (see  Figure  9-4).  The  format  for  this  table  consists  of  the  statistic 
name  in  the  left-hand  column  and  the  name  of  each  port  at  the  top  of  the 
column. 

The  tonnage  statistics  include  "total  tonnage  into  port"  and  the 
"total  tons  out  of  port".  Each  total  is  decomposed  into  the  following 
cargo  types: 

(1)  "overseas"  -  all  cargo  carried  by  saltwater  vessels 

(2)  "liquid  bulk"  -  all  cargo  carried  by  tankers 

(3)  "dry  bulk  (excl. grain)"  -  all  dry  bulk  excluding  grain 

(4)  "grain"  -  all  grain  shipments. 

These  statistics  are  accumulated  values  giving  the  total  tonnage  by  cargo 
type  carried  by  all  vessels  into  and  out  of  each  port.  The  statistics  do 
not  include  any  cargo  which  may  be  in  the  process  of  being  loaded  onto  a 
vessel,  nor  do  they  include  the  commodity  inventory  at  port  (i.e.,  cargo 
not  committed  to  any  vessel). 


J,  TABLE  9 

Table  9  presents  the  total  number  of  vessels  entering  and  exiting 
each  port  (see  Figure  9-5).  This  table  is  similar  to  Table  8  in  that 
the  format  is  similar  and  each  statistical  total  is  broken  down  into  the 
same  cargo  types.  Thus,  "overseas"  is  interpreted  as  the  number  of 
saltwater  vessels  and  "grain"  means  the  number  of  dry  bulk  vessels  trans¬ 
porting  grain. 
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FIGURE  9-4  TABLE  8  in  PROSIM 


TABLE  9  PERFORMANCE  DETAILS  FOR  PORTS 
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FIGURE  9-5  TABLE  9  in  PROSIM 


K.  TABLE  10 


Table  10  presents  two  statistics,  "average  turnaround  time"  and 
"average  delay  for  berth  use,"  for  all  vessels  processed  at  each  port 
(see  Figure  9-6).  These  statistics  are  presented  according  to  the  same 
cargo  types  defined  previously. 

Average  turnaround  time  is  the  average  of  all  times  spent  by  vessels 
at  a  port  and  is  computed  as  the  time  between  a  vessel's  entry  into  a  port 
and  its  subsequent  exit  from  that  port.  This  statistic  includes  any 
delays  experienced  while  waiting  for  suitable  cargo  or  for  a  berth  or  due 
to  any  random  delay  factor  as  well  as  the  actual  loading  and  unloading 
times. 

Average  delay  for  berth  use  is  more  specifically  the  average  delay 
encountered  by  vessels  delayed  by  the  unavailability  of  a  suitable  berth 
for  unloading  or  loading  or  both.  This  statistic  is  computed  for  delayed 
vessels  only  and  does  not  include  zero-delayed  vessels  or  vessels  encounter¬ 
ing  types  of  delays  other  than  the  ones  mentioned. 


L.  TABLE  11 

Table  11  is  produced  optionally  at  the  user's  specification  and 
supplies  the  "average  queue  for  berth  use"  and  the  "average  loading  time" 
(see  Figure  9-7).  These  statistics  are  presented  according  to  previously 
defined  cargo  types. 

Average  queue  for  berth  use  is  the  average  length  of  a  berth  queue 
and  consists  of  the  average  number  of  vessels  awaiting  a  free  berth  for 
loading  or  unloading. 


Average  loading  time  is  defined  as  the  average  of  all  times  spent  by 


vessels  in  a  berth  for  the  loading  process.  This  statistic  is  supplied 
for  calibration  purposes  so  that  the  user  may  verify  that  the  value  given 
indeed  represent  the  input  data  for  ports. 


M.  TABLE  12 


Table  12  is  also  generated  at  the  user's  option  and  consists  of  two 
statistics.  "Average  unloading  time"  is  the  average  time  spent  by  vessels 
in  a  berth  for  unloading,  broken  down  by  the  four  cargo  types.  The  "wait 
for  cargo  summary"  statistic  is  comprised  of  two  elements.  "No.  of  ships 
waiting"  is  the  total  number  of  vessels,  regardless  of  type,  waiting  in 
cargo  queues  for  a  suitable  cargo.  "Weighted  queue  length"  is  a  time- 
dependent  variable  which  weights  a  collection  of  queue  size  observations  by 
the  length  of  time  they  have  had  their  values.  This  variable  is  calculated 
as  follows: 


V 


where 


n  = 


T  - 

c 


T  - 

n 

C  - 


Number  of  times  queue  size  changes,  i.e.,  number  of  times 
vessels  enter  and  exit  cargo  queue 

Sample  value  of  cargo  queue  size  before  it  changes  to 
to  a  new  value 

Simulation  time  at  which  cargo  queue  was  set  to  its 
current  value 

Simulation  time  at  which  cargo  queue  changes  to  a  new  value 
Simulation  time  at  printout. 
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This  output  is  a  better  measure  of  the  state  of  the  cargo  queue  than  a 
simple  time  independent  average  and  is  given  in  Table  12  for  calibration 
purposes.  Inordinately  large  values  for  this  statistic  may  indicate 
abnormal  imbalance  between  transportation  supply  and  demand.  Figure  9-8 
provides  an  example  output  for  Table  12. 


N.  TABLE  13 

Table  13  gives  performance  details  for  reaches  (see  Figure  9-9). 
Included  are  the  following  statistics: 

"No.  of  total  ships" 

"Average  transit  time" 

"Total  transit  time" 

"Std  error  for  transit." 

These  statistics  are  given  for  each  class  of  vessels,  and  are  computed  in 
the  previously  described  manner.  This  output  is  generated  when  vessels 
complete  their  transit  through  reaches;  the  output  does  not  include  vessels 
in  the  process  of  passage  at  the  time  of  printout. 

O.  TABLE  14 

Table  14  gives  the  "total  no.  of  ships"  and  the  "total  transit  time" 
measures  for  each  lake  in  the  system  (see  Figure  9-10),  where  these 
statistics  are  defined  as  previously.  Additional  output  such  as  average 
transit  times  are  not  computed  since  they  vary  between  different  node 
points  on  the  lake. 


TABLE  12  PERFORMANCE  DETAILS  FOR  PORTS 


FIGURE  9-9  TABLE  13  in  PROSIM 


TABLE  14  PERFORMANCE  DETAILS  FOR  LAKES 


FIGURE  9-10  TABLE  14  in  PROSIM 


P .  TABLE  15 


Table  15  provides  the  summary  statistics  for  the  Welland  Canal  as 
represented  in  NETSIM  II.  The  format  of  the  table  and  the  statistics 
generated  are  shown  in  Figure  9-11. 

The  first  statistic  is  the  "total  number  of  ships"  entering  the  Canal, 
an  accumulated  statistic.  The  second  statistic  is  the  "total  tonnage" 
carried  by  vessels  entering  the  Canal,  also  an  accumulated  statistic.  Both 
of  these  outputs  are  broken  down  according  to  whether  they  belong  to  overseas, 
dry  bulk  or  liquid  bulk  categories.  The  third  output  is  the  "average  transit 
time",  computed  as  the  average  time  spent  in  the  Canal.  The  final  output  is 
the  "average  waiting  time",  a  calculated  delay  statistic. 
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TABLE  15  PERFORMANCE  DETAILS  FOR  THE  WELLAND  CANAL 


TOTAL  NUMBER  OF  SHIPS 
OVERSEAS 
LIQ  BULK 
DRY  BULK 

TOTAL  TONNAGE 
OVERSEAS 
LIQ  BULK 
DRY  BULK 

AVERAGE  TRANSIT  TIME 
AVERAGE  WAITING  TIME 


FIGURE  9-11  TABLE  15  in  PROSIM 
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APPENDIX  C 

PROSIM  USER  MANUAL 
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A.  INTRODUCTION 


This  manual  provides  the  information  needed  to  prepare  the  input  data 
for  the  PROSIM  portion  of  the  simulation  package.  It  is  assumed  that  the 
reader  is  thoroughly  familiar  with  Part  I  of  this  publication  dealing  with 
the  input,  output  and  operations  of  NETSIM  II.  Since  the  numbering  con¬ 
ventions  used  to  input  data  for  PROSIM  must  agree  completely  with  those 
used  in  NETSIM  II,  such  familiarity  is  indispensable. 

B.  INPUT  DATA  FORMATS 

A  PROSIM  data  deck  consists  of  the  two  classes  of  data  described  in 
Chapter  7.  Some  of  these  data  are  in  fixed  format  and  others  can  be  input 
in  free  form.  For  the  latter,  there  are  two  governing  restrictions.  First, 
each  datum  must  be  separated  from  its  adjoining  data  by  at  least  one  blank. 
Second,  a  datum  must  not  be  continued  from  one  card  to  the  next.  Data  may 
be  punched  as  either  real  or  integer  except  as  otherwise  specified.  The 
important  thing  to  remember  about  the  free-form  concept  is  that  the  program 
reads  free-form  input  as  a  continuous  stream  of  values.  Successive 
numerical  values  are  read  and  assigned  to  corresponding  variables  in  the 
read  command.  The  location  of  a  particular  datum  on  a  card  is  not  con¬ 
sidered,  (except  as  noted — some  data  must  start  in  column  1  where  indicated) 
as  long  as  it  is  properly  positioned  relative  to  other  data.  Unless  other¬ 
wise  stated,  all  data  below  can  be  input  in  free  form. 


Card  Format  Specifications 


Item 

Number 

A1 

A2 

A3 

A4 

A5 

A6 

A7 

A8 

A9 

A10 

All 

A12 

A13 


Contents 


N.PORT 

Number  of  ports. 

N.LOCK 

Number  of  locks. 

N. REACH 

Number  of  reaches. 

N.LAKE 

Number  of  lakes. 

SWITCH. FOR. WELLAND 

This  code  is  1  if  NETSIM  II' s  representation 
of  the  Welland  Canal  is  to  be  used,  0  otherwise. 

N. VESSEL 

Number  of  vessels — this  number  need  not  be 
exact  but  it  must  be  equal  to  or  greater  than 
the  number  of  vessels  used  in  NETSIM  II.  A 
lower  number  will  result  in  program  termination 
with  an  addressing  error. 

SEASON. LENGTH 

This  is  the  total  simulation  time  including  any 
warm-up  time  needed  to  achieve  steady  state. 

WARMUP. TIME 

This  is  the  warm-up  period  for  locks,  reaches 
and  lakes. 

PRT. WARMUP. TIME 
Warm-up  period  for  ports. 

INTER. MEDIATE .PRINTOUT 

Simulation  interval  between  intermediate 
statistical  reports. 

HI. PORT 

Identification  number  of  the  highest  numbered 
port. 

HI . LOCK 

Identification  number  of  the  highest  numbered 
lock. 

HI. REACH 

Identification  number  of  the  highest  numbered 
reach. 
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Item 

Number  Contents 


A14  HI. LAKE 

Identification  number  of  the  highest  numbered 
lake. 

A15  1. CLASS 

Vessel  length  upper  bound  for  Class  1,  in  tens 
of  feet. 

A16  2. CLASS 

Vessel  length  upper  bound  for  Class  2,  in  tens 
of  feet. 

A17  GRN. INDEX 

Code  representing  grain  cargo. 

A18  P. DEVICE 

Output  unit  for  punching  selected  statistics. 

A19  INPUT. DEVICE 

Input  unit  for  reading  the  NETSIM  II  event  log. 

A20  0.1 

This  code  is  1  if  the  lock  tables  1  through  7 

are  to  be  printed  during  the  intermediate 
printouts,  0  otherwise. 

A21  0. 2 

This  code  is  1  if  the  port  tables  8  through  10 

are  to  be  printed  during  the  intermediate 
printouts,  0  otherwise. 

A22  0.3 

This  code  is  1  if  Table  13  (reach)  is  to  be 
printed  during  the  intermediate  printouts,  0 
otherwise . 

A23  0.4 

This  code  is  1  if  Table  14  (lake)  is  to  be 
printed  during  the  intermediate  printouts, 

0  otherwise. 

A24  CAL . ID 

This  code  is  1  if  the  port  tables  11  and  12 
are  to  be  printed  (both  for  intermediate 
printouts  and  final  printout),  0  otherwise. 

A25  RUN. ID 

Identification  number  for  the  simulation  run. 


Item 

Number 


Contents 


A26 


A27 


Card 

Card 

Card 


Identification  Numbers 

PROSIM  requires  identification  numbers  for 
each  fixed  facility  in  the  system  and  the 
numbers  given  must  agree  exactly  with  those 
in  NETSIM  II  (see  the  section  on  "Numbering 
Convention  in  NETSIM  II"  in  the  NETSIM  II 
User  Manual,  pp.  58-60  of  this  publication). 
The  order  in  which  the  identification  numbers 
are  given  is  as  follows  (free  form) : 

Starting  in  cc  1  of  a  new  card, 

identification  number  for  each  port 
identification  number  and  upstream  node 
for  each  lock 

identification  number  for  each  reach 
identification  number  for  each  lake. 

That  is,  the  identification  numbers  for  ports 
must  precede  those  for  locks,  etc. 

Alphameric  Names 

PROSIM  requires  an  alphameric  name  for  each 
fixed  facility  in  the  system  (ports,  locks, 
reaches  and  lakes).  A  name  can  consist  of  up 
to  eight  characters.  The  names  must  be  given 
in  the  same  sequence  as  the  identification 
numbers  (item  A26).  Each  name  is  in  columns 
1-8  of  a  new  card  (one  name  per  card).  Within 
each  category  of  facilities,  the  input  names 
must  be  ordered  by  the  sequence  of  their 
identification  number.  This  is  illustrated 
below. 


Ports 

1  cc  1-8  Name  of  the  first  port  (port  with  identification 

number  =  1) 

2  cc  1-8  Name  of  the  second  port 


10 


cc 


1-8 


Name  of  the  tenth  port 


Locks 

cc  1-8  Name  of  the  first  lock 
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Reaches 


cc  1-8  Name  of  the  first  reach 

« 

Lakes 

cc  1-8  Name  of  the  first  lake 

These  input  data  must  be  supplied  in  the  exact  order  and  manner  as  shown 
above . 


B1  NETSIM  II  EVENT  LOG 

The  event  log  is  a  collection  of  data  records 
generated  as  output  by  NETSIM  II  and  input  to 
PROSIM  through  an  auxiliary  device  such  as 
magnetic  tape,  card  file,  etc.  Each  record 
in  the  event  log  has  eleven  elements  with 
the  following  format  (414,13,11,12, 
11,214,  D (7 ,0)  ). 


Item 

Column 

Format 

Description 

1 

1-4 

I  4 

Vessel  identification  number 

2 

5-8 

I  4 

Vessel  length  in  tens  of  feet 

3 

9-12 

I  4 

Vessel's  current  node  number 

4 

13-16 

I  4 

Vessel's  riext  node  number 

5 

17-19 

I  3 

Vessel's  cargo  tonnage  in  hundreds  of  tons 

6 

20 

I  1 

Commodity  type 

7 

21-22 

I  2 

Code  for  dedicated  cargo 

8 

23 

I  1 

Vessel  classification  code 

9 

24-27 

I  4 

Facility  identification  number 

10 

28-31 

I  4 

Event  code 

11 

32-38 

0(7,0) 

Simulation  time 
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C .  ERROR  MESSAGES 


This  section  describes  all  error  messages  generated  by  PROSIM.  The 
possible  reasons  for  the  generation  of  each  massage  and  recommended  user 
action  are  also  described.  PROSIM’s  error  messages  are  most  often  the 
result  of  some  inconsistency  between  its  input  data  and  that  for  NETSIM  II. 
To  avoid  costly  reruns,  the  user  is  urged  to  inspect  his  data  carefully  in 
order  to  insure  that  this  is  not  the  case. 

- PROSIM  ERROR  MESSAGE  1101 - 

UNIDENTIFIABLE  FACILITY  ID  AAAA  IN  SIMULATION  EVENT.LOG  WITH  EVENT. CODE 
BBBB  AT  SIMULATION  TIME  CCCCCC 

This  error  is  discovered  by  the  event  log  processor  routine  and  may 
be  attributed  to  the  following: 

(1)  incorrect  identification  numbers  (item  A26)  due  to  keypunch 
mistakes,  omission  of  a  number,  etc.,  or  inconsistency  with 
the  identification  numbers  input  to  NETSIM  II; 

(2)  access  to  the  wrong  NETSIM  II  event  log. 

- PROSIM  ERROR  MESSAGE  1201 - 

INCORRECT  CLASSIFICATION  NUMBER  AAAA  IN  SIMULATION  EVENT.LOG 
WITH  VESSEL  ID  DDDD  EVENT. CODE  BBBB  AT  SIMULATION  TIME  CCCCCC 

The  vessel  classification  codes  in  the  NETSIM  II-PROSIM  simulation 
package  are  as  follows: 

1  ■  saltwater  vessels 

2  -  liquid  bulk  carriers 

3  ■  dry  bulk  carriers. 


-172- 


Any  deviation  from  this  numbering  scheme  will  result  in  the  above  error 
and  program  termination.  There  are  three  corrective  actions  listed  in 
order  of  increasing  programming  difficulty: 

(1)  rerun  NETSIM  II  simulation  with  correct  vessel  classification 
codes; 

(2)  modify  the  event  log  to  reflect  the  correct  codes; 

(3)  modify  PROSIM  to  accept  user's  numbering  system. 

- PROSIM  ERROR  MESSAGE  1301 - 

INCORRECT  CLASSIFICATION  NUMBER  AAAA  FOR  EVENT. CODE  9180  IN  SIMULATION 

EVENT.LOG  WITH  VESSEL  BBBB  - PORT  CCCC  AT  SIMULATION  TIME  DDDDDDD 

Vessel  classification  code  should  be  1  for  event  code  9180  in 
NETSIM  II.  The  user  is  referred  to  the  corrective  action  listed  for 
error  1201. 

- PROSIM  ERROR  MESSAGE  1302 - 

ERROR  FOR  EVENT. CODE  9190  IN  SIMULATION  PROGRAM  VESSEL  AAAA  - PORT 

BBBB  - TIME  CCCCCCC 

This  error  indicates  an  identification  number  of  0  for  a  destination 
port  in  the  commodity  arrival  list  input  for  NETSIM  II,  hence,  the  error 
would  normally  be  discovered  during  simulation.  If  this  error  does  reach 
PROSIM,  this  is  an  indication  of  a  basic  abnormality  in  the  numbering 
scheme  for  NETSIM  II.  The  user  should  reevaluate  NETSIM  II  input  data  and 
submit  a  revised  run. 

- PROSIM  ERROR  MESSAGE  5101 - 

INCORRECT  CLASSIFICATION  NUMBER  AAAA  IN  SIMULATION  EVENT.LOG  WITH 

VESSEL  BBBB  - EVENT. CODE  CCCC  AT  TIME  DDDDDDD 

This  error  is  encountered  by  the  Welland  passage  routine.  Corrective 
action  is  listed  under  error  1201. 
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PART  III 

SUPPORT  PROGRAMS  FOR  THE  SIMULATION  PACKAGE — 
DESCRIPTIONS  AND  USER  MANUALS 


CHAPTER  10.  VESSEL  GENERATION  PROGRAM 


A.  PROGRAM  DESCRIPTION 

This  program  produces  CREAT. VESSEL  external  event  notices  for  direct 
input  into  NETSIM  II.  The  user  must  supply,  as  data,  a  "pool"  of  repre¬ 
sentative  vessels.  The  program  then  generates  vessel  arrivals  into  the 
system  (CREAT. VESSEL  cards)  at  specified  times  by  making  random  selections 
from  this  pool  according  to  user-specified  probability  distributions.  The 
ports  into  which  the  vessels  are  introduced  are  then  chosen  independently 
according  to  another  set  of  distributions. 

More  specifically,  the  user  must  supply  the  following: 

1.  Pool  of  representative  vessels.  This  is  really  three 
separate  pools,  one  for  each  of  the  three  vessel 
classifications  (dry  bulk,  liquid  bulk  and  saltwater). 

For  each  vessel  in  the  pool  must  be  supplied  data  for 
all  of  the  attributes  that  appear  in  the  CREAT .VESSEL 
card.  Also,  for  each  vessel  the  user  must  give  the 
frequency  with  which  it  will  be  selected  relative  to 
other  vessels  in  the  pool  with  the  same  vessel' clas¬ 
sification.  These  frequencies  are  given  as  decimal 
fractions  which  must  add  to  unity  within  each  classi¬ 
fication. 

2.  Port  data.  For  each  port-vessel  classification  combina¬ 
tion,  the  user  must  specify  the  probability  that  a 
vessel  of  the  given  class  will  be  introduced  into  the 
system  at  the  given  port.  Again,  the  probabilities 
within  each  classification  must  sum  to  unity. 

3.  Vessel  creation  time  specification.  This  is  simply  a 
series  of  cards,  each  of  which  gives 

(a)  the  number  of  each  class  of  vessel  to  be  created 

(b)  when  they  are  to  be  created. 

A  new  card  is  required  for  each  different  time  (simula¬ 
tion  time),  but  there  is  no  limit  to  the  number  of 
vessels  to  be  created  (CREAT. VESSEL  cards  to  be  gener¬ 
ated)  from  a  single  card.  (All  of  the  CREAT. VESSEL 
cards  generated  from  a  single  input  data  card  will 
have  the  same  value  in  the  TIME.V  field). 
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Production  of  CREAT. VESSEL  cards  by  the  program  is  rather  straight¬ 
forward,  proceeding  as  follows: 

1.  A  vessel  creation  time  specification  card  (see  3  above) 
is  read  in.  This  specifies  a  time  and  the  number  of 
vessels  to  be  generated  in  each  class. 

2.  Beginning  with  vessel  class  1,  a  vessel  (set  of  vessel 
attributes)  is  selected  from  the  pool  of  vessels  of 
that  class  according  to  the  given  probability  distri¬ 
bution. 

3.  A  port  is  selected  according  to  the  port  selection 
probability  distribution  for  the  given  vessel  class. 

4.  A  CREAT. VESSEL  record  is  written  (to  unit  1)  with  the 
given  time  and  the  selected  port  and  vessel  attributes. 

Steps  2  through  4  are  repeated  until  the  specified  number  of  vessels 
of  each  class  have  been  created.  Then  the  next  vessel  creation  time 
specification  card  is  read  and  the  process  is  continued.  The  run  terminates 
when  no  more  cards  remain  to  be  read.  Generated  vessels  are  numbered 
sequentially,  beginning  with  one.  These  numbers  are  placed  in  columns  66 
through  71  of  the  CREAT. VESSEL  records  by  the  program. 

Immediately  following  is  a  user  manual  which  describes  the  data  require¬ 
ments  and  outputs  in  detail. 

B.  USER  MANUAL 
1.  Input  Data  Stream 

In  the  following  data  descriptions  all  numbers  are  to  be  punched 
right  justified  in  the  indicated  fields  with  no  decimal  points.  The  user 
should  keep  in  mind  that  both  trailing  and  leading  blanks  are  interpreted 
as  zeroes.  Note  that  a  number  of  vessel  attributes  are  required  in  card 
type  2.  For  convenience,  these  are  in  the  same  card  columns  in  which  they 
appear  in  the  CREAT. VESSEL  cards.  For  further  description  of  che  attributes 
refer  to  Chapter  2  and  pages  83-85  in  Appendix  A. 
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Card 


Tjr2e 

Columns 

Description 

1 

1-10 

Number  of  representative  vessels 
in  the  classification  1  pool,  NVES1. 

2 

1-10 

1000  times  the  probability  of 
selecting  this  vessel. 

24-27 

OVERALL. LENGTH(VESSEL)  in  tens  of 
feet. 

28-33 

HORSEPOWER (VESSEL)  in  hundreds  of 
horsepower. 

34-39 

CAPACITY (VESSEL)  in  hundreds  of 
tons. 

40-44 

UNLOADING. RATE (VESSEL)  (for  self¬ 
unloading  vessels  only). 

45-47 

DRAFT (VESSEL)  in  feet. 

48-49 

CLASSIF(VESSEL) 

50-53 

MT. BACK (VESSEL) 

54-59 

CARGO. TONNAGE (VESSEL)  in  hundreds 
of  tons. 

60-61 

CARG.TYP (VESSEL) 

62-65 

ORIGIN (VESSEL) 

The  number  of  type  2  cards  is  NVES1; 
that  is,  one  for  each  vessel  in  the 
class  1  pool. 

3 

1-10 

Number  of  representative  vessels  in 
the  classification  2  pool,  NVES2. 

4 

Same  format  as  card  type  2.  There 
are  NVES2  of  these. 

5 

1-10 

Number  of  representative  vessels  in 
the  classification  3  pool,  NVES3. 

6 

Same  format  as  card  type  2.  There 
are  NVES3  of  these. 

7 

1-10 

Number  of  ports,  NP0RT. 

8 

1-10 

Port  number. 
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Card 

Type  Columns  Description 

11-20  1000  times  the  probability  of  this 

port's  being  selected  as  the  entry 
point  for  a  class  1  vessel. 

21-30  1000  times  the  probability  of  this 

port's  being  selected  as  the  entry 
point  for  a  class  2  vessel. 

31-40  1000  times  the  probability  of  this 

port's  being  selected  as  the  entry 
point  for  a  class  3  vessel. 

There  is  one  type  8  card  for  each  port. 

9  1-10  Time  that  vessels  are  to  be  created. 

TIME.V 

11-20  Number  of  class  1  vessels  to  be 

created  at  time  TIME.V. 

21-30  Number  of  class  2  vessels  to  be 

created  at  time  TIME.V. 

31-40  Number  of  class  3  vessels  to  be 

created  at  time  TIME.V. 

There  is  one  type  9  card  for  each 
time  that  one  or  more  vessels  are 
to  be  created. 


2.  Outputs 

The  primary  output  is  cards  that  serve  as  CREAT. VESSEL  external  event 
notices  in  NETSIM  II.  The  format  is  as  follows: 


Columns 


Description 


Characters  "CREAT. VESSEL" 


13-20  Simulation  >time  that  the  event  is  to  occur 

(TIME.V).  Tne  number  is  in  an  F  format, 
so  that  the  character  in  column  20  is  a 
decimal  point. 


21-23 


Number  of  the  port  into  which  the  vessel  is 
to  be  introduced. 


Columns 


24-71 


80 


Attribute  data  for  the  vessel.  The 
format  is  identical  to  that  for  a  type 
2  input  card,  described  above. 


Signals  end  of  data  for  an  external 
event  notice. 


In  addition  to  producing  CREAT. VESSEL  cards,  the  program  prints  out 
the  number  of  each  class  of  vessel  which  will  be  created  at  each  port. 
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CHAPTER  11.  COMMODITY  ARRIVAL  GENERATION  PROGRAM 


A.  PROGRAM  DESCRIPTION 

This  program  produces  COM. ARRIVAL  external  event  notices  for  direct 
input  into  NETSIM  II.  These  provide  for  the  simulation  of  overland 
arrivals  of  commodities  into  ports  in  the  system.  The  program  allows  only 
for  a  uniform  (periodic)  deterministic  flow  of  commodities  into  each  port. 
It  is  intended  merely  as  an  expedient  for  data  preparation  in  that  it 
relieves  the  user  of  the  task  of  physically  reproducing  the  data  for  each 
inter-arrival  period.  The  commodities  which  are  introduced  into  the  ports 
in  this  manner  are,  of  course,  those  that  will  in  the  future  become  cargoes 
for  the  vessels  in  the  system.  For  each  module  of  cargo  must  be  specified 

(1)  the  port  at  which  it  is  arriving 

(2)  the  commodity  type 

(3)  its  destination  within  the  system 

(4)  the  quantity. 

Following  is  a  user  manual  which  describes  the  program's  inputs  and 
outputs  in  detail. 


B.  USER  MANUAL 
1.  Input  Data  Stream 

All  values  must  be  right- justified  in  the  indicated  fields.  The 
user  should  keep  in  mind  that  all  leading  and  trailing  blanks  are  inter¬ 
preted  as  zeroes. 

Card 
Type 

1 
2 
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Columns  Description 

1-10  The  number  of  type  2  cards  to  follow. 

1-10  Fort  number  into  which  the  commodity 

is  to  be  introduced. 


Card 

II E£ 


3 


Columns 

11-20 

21-30 

31-40 


1-10 


Description 

Commodity  type. 

Destination  (port  number). 

Commodity  quantity  in  hundreds  of  tons. 

There  will  be  one  type  2  card  for  each 
port-commodi ty-des  tination  combination . 
The  type  2  cards  must  be  sequenced  in 
increasing  order  by  commodity  type 
within  port  number.  The  last  type  2 
card  must  have  zeroes  in  all  four  fields 
to  signal  end  of  data  (to  the  NETSIM  II 
program) . 

Time  (simulation  time)  at  which  the 
commodity  arrivals  described  in  the 
type  2  cards  are  to  occur. 

There  will  be  one  type  3  card  for  each 
time  at  which  commodities  are  to  arrive 
in  port. 


2.  Outputs 

The  only  program  output  consists  of  the  COM. ARRIVAL  event  notices. 
Each  event  notice  is  made  up  of  several  records  as  follows : 


Card 

ll E£. 
1 


2 


Columns  Description 

1-11  Characters  "COM. ARRIVAL". 

12-20  Time  that  the  external  event  is  to 

occur  (TIME.V).  That  is,  the  simula¬ 
tion  time  at  which  the  commodities 
are  to  arrive  in  port.  The  format 
type  is  "F",  so  that  column  20  always 
contains  a  decimal  point. 

The  format  and  data  are  identical  to 
those  for  type  2  cards  in  the  input 
stream.  That  is,  the  type  2  input 
cards  are  reproduced  without  change. 


3 


1 


signals  end  of  data  in  the  external 
event  notice. 


This  sequence  of  output  records  is  repeated  for  each  type  3  input 
card.  Note  that  the  output  records  are  referred  to  as  "cards",  but  they 
can  just  as  easily  be  80  character  records  on  disk  or  tape. 


CHAPTER  12.  ITINERARY  GENERATION  PROGRAM 


A.  PROGRAM  DESCRIPTION 

This  is  a  FORTRAN  program  which  generates  itineraries  for  saltwater 
vessels  in  NETSIM  II.  The  itineraries  are  written  in  a  format  which  is 
directly  readable  by  the  NETSIM  II  program  (in  the  routine  ENT. PORT).  Each 
itinerary  consists  of 

(1)  The  number  of  stops  (ports) 

(2)  For  each  stop 

(a)  the  port  number 

(b)  the  fraction  of  the  vessel's  tonnage  to  unload 
at  the  port 

(c)  the  fraction  of  the  tonnage  (capacity)  to  load  at 
the  port. 

It  Is  assumed  that  the  saltwater  vessels  are  entering  the  system  via 
the  St.  Lawrence  River.  Figure  12-1  shows  schematically  the  shape  of  the 
network  for  which  this  program  is  designed.  It  would  not  be  applicable  to 
a  system  with  any  other  configuration.  Figure  12-2  illustrates  that  the 
Great  Lakes-St.  Lawrence  Waterway  System  fits  the  scheme.  The  primary 
aspects  of  the  scheme  are: 

(1)  There  is  only  a  single  point  at  which  a  vessel  may 
enter  or  leave  the  system. 

(2)  At  the  "other  end"  of  the  system  from  the  entry/exit 
point  is  a  fork  creating  two  distinct  branches. 

(3)  At  some  point  between  the  fork  and  the  entry/exit 
point,  the  system  is  conceptually  divided  into  upper 
and  lower  subsystems. 
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Figure  12-1.  Schematic  Representation  of  the  Network  Used 
in  the  Itinerary  Generation  Program 


For  Che  GL-SLS,  Che  dividing  point  is  Che  Welland  Canal.  The  program 
generaces  itineraries  such  that  Branch  1  and  Branch  2  are  never  both 
entered  on  the  same  itinerary. 

There  are  a  number  of  empirical  statistics  that  can  be  used  to 
describe  actual  itineraries  of  saltwater  vessels.  Not  all  such  parameters 
can  be  specified  independently  for  purposes  of  random  itinerary  generation, 
however.  Hence,  decisions  had  to  be  made  as  to  which  parameters  would  be 
inpuC  by  the  user  and  which  would  subsequently  be  calculated  automatically 
by  the  program.  The  following  example  illustrates  this  point. 

Adopt  the  following  notation: 

E(X)  expected  value  of  a  random  variable,  X 

Let  P  *  probability  that  a  vessel  goes  through  Welland 

Tj  »  total  inbound  tonnage  (into  the  system  on  saltwater  vessels) 

TQ  *  total  outbound  tonnage 
TIA  *  total  inbound  tonnage  terminating  above  Welland 
TQA  *  total  outbound  tonnage  originating  above  Welland 
TIB  T0B  similarly  (for  below  Welland) 

Pj  F^  specify  the  distribution  of  the  fraction  of  inbound 
*  tonnage  dropped  off  above  Welland  by  a  vessel  which 

goes  through  Welland  (F.  of  the  tonnage  with  probability 

V- 

Then: 

(1-P)  +  P-[£  Pi(l-Fi)  ]  -  Tib  /Tj. 

(1-P)  +  P-  (l-E(F)  )  -  Tib/Tl 
P*E(F)  -  1  -  TIB  -  TIA 


Tj  •  E(F) 


Hence,  specification  of  the  distribution  of  the  fraction  of  a 
vessel's  inbound  tonnage  which  terminates  above  Welland  (P^,  F^)  uniquely 
determines  P,  the  proportion  of  vessels  which  go  through  Welland.  This 
assumes  that  we  know  the  fraction  of  inbound  tonnage  which  terminates  above 
(as  opposed  to  below)  Welland. 

Required  data  inputs  for  the  program  are  as  follows: 

1.  For  each  port 

(a)  port  number 

(b)  on  which  of  the  branches  of  the  network  it  lies 

(c)  annual  inbound  tonnage 

(d)  annual  outbound  tonnage. 

2.  The  frequence  distribution  (P^,  F^)  of  the  fraction  of  a 

vessel's  inbound  tonnage  which  terminates  above  Welland 

(given  that  the  vessel  goes  through  Welland) . 

3.  Frequency  distributions  of 

(a)  The  number  of  stops  for  a  vessel  that  does  not  go 
through  Welland 

(b)  The  number  of  stops  above  Welland  for  a  vessel  that 
goes  through  Welland 

(c)  The  number  of  stops  below  Welland  for  a  vessel  that 
goes  through  Welland. 

4.  The  probability  of  selecting  Branch  1  as  opposed  to  Branch  2. 

In  generating  itineraries,  the  program  must  first  randomly  determine 
whether  the  vessel  is  to  go  through  Welland.  If,  say,  it  is  to  go  through 
Welland,  then  samples  must  be  taken  from  distribtuions  3(b)  and  3(c)  above, 
respectively,  to  determine  the  number  of  stops  above  and  below  Welland. 
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The  two  segments  of  the  itinerary  are  then  generated  independently.  For 

each  port,  a  determination  is  made  randomly  as  to  whether  that  port  is  to 

be  in  the  subitinerary.  If  the  number  of  ports  selected  is  equal  to  the 

required  number,  this  group  of  ports  will  go  into  the  itinerary.  If  not, 

the  selected  group  is  saved  in  a  table  for  possible  later  use.  For  example, 

suppose  sampling  from  distribution  3(b)  yields  a  value  3.  This  means  there 

are  to  be  three  stops  above  Welland.  The  storage  table  is  first  consulted 

• 

to  see  if  a  subitinerary  of  three  ports  above  Welland  is  available  from 
previous  generation.  If  so,  it  will  be  used.  If  not,  more  subitineraries 
will  be  generated  until  one  with  three  ports  is  produced.  All  those  that 
are  generated  with  fewer  than  three  or  more  than  three  ports  will  be  saved 

for  possible  later  use.  Note  that  in  generating  subitineraries  for  above 

Welland,  either  Branch  1  or  Branch  2  must  be  selected,  but  not  both. 

Random  selection  of  ports  for  subitineraries  is  based  upon  the  frequency 
of  calls  by  saltwater  vessels  at  the  various  ports.  Define  the  following 
FORTRAN  variables: 

NSA  relative  total  number  of  salt  vessel  calls  above  Welland 

NSB  relative  total  number  of  salt  vessel  calls  below  Welland 

NSVCAL(I)  relative  total  number  of  salt  vessel  calls  at  port  I 

SVT1(I)  relative  total  salt  vessel  tonnage  inbound  to  port  I 

SVTO(I)  relative  total  salt  vessel  tonnage  outbound  from  port  I 
EPAW  E  (number  of  stops  per  itinerary  above  Welland  (  go  through 

Welland) 

EPBW  E  (number  of  stops  per  itinerary  below  Welland  |  go  through) 

EPBW1  E  (number  of  stops  per  itinerary  I  don’t  go  through) 

PCA(I)  P  (choose  port  I  |  go  through  and  branch  for  port  I  is 

chosen).  I  above  Welland. 
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PCAF(I) 


-  1 

| 

P  (choose  port  I  |  go  through).  I  above  Welland. 

PCB(I)  P  (choose  port  I  I  go  through).  I  below  Welland. 

PCB1(I)  P  (choose  port  I  I  don't  go  through). 

PCBF(I)  P  (choose  port  I).  I  below  Welland. 

PCBR(I)  P  (choose  the  branch  on  which  port  I  lies  I  go  through). 

I  above  Welland. 

PTW  P  (go  through  Welland) 

Total  number  of  calls  and  total  tonnage  are  "relative"  in  that  the 
absolute  numbers  are  not  important;  only  the  ratios  are  used.  The  decision  I 

was  made  not  to  require  NSVCAL (  )  as  input  data.  Rather,  it  is  assumed 

that  the  number  of  calls  at  each  port  is  proportional  to  the  outbound 
tonnage.  Thus,  the  program  makes  the  substitution 

NSVCAL(I)  =  SVTO(I). 

If  the  user  should  desire  to  supply  NSVCAL(  )  as  data,  modification 
of  the  program  to  accommodate  this  change  would  be  relatively  simple. 

Calculation  of  the  probabilities  of  selecting  ports  for  itineraries  is  as 


follows : 

NSA 

= 

V  NSVCAL(I) 
ports  above 

Welland 

NSB 

'y  NSVCAL(I) 
ports  below 

Welland 

PCAF(I) 

m 

NSVCAL(I)*EPAW/NSA 

PCA(I) 

m 

PCAF(I)/PCBR(I) 

PCB(I) 

3> 

NSVCAL (I)*EPBW/NSB 

PCB1(I) 

m 

NSVCAL (I)*EPBW1/NSB 

PCBF(I) 

m 

PTW*PCB(1)  +  (1-PTW)*PCB1(I) 
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First,  the  decision  is  made  as  to  whether  the  vessel  will  pass  through 
Welland.  If  not,  the  ports  (all  below  Welland)  are  selected  according  to 
the  probabilities  PCB1(I).  If  the  vessel  is  to  pass  through  Welland, 

Branch  1  or  Branch  2  is  selected,  then  ports  are  chosen  according  to 
probabilities  PCA(I)  and  PCB(I). 

After  all  of  the  ports  have  been  selected  for  the  itinerary,  the  next 
step  is  to  determine  the  fractions  of  the  vessel's  tonnage  to  be  loaded  and 
unloaded  at  each  port.  Define  additional  FORTRAN  variables: 


PTAWI(  ) 


PTAWO (  ) 

AI 

AO 

PON (I) 


POFF(I) 


PN(I) 


PF(I) 


Contains  the  distribution  of  the  fraction  of 
inbound  tonnage  that  a  vessel  will  unload  above 
Welland  given  that  the  vessel  passes  through 
Welland 

Similarly  for  outbound  tonnage 
A  random  variate  from  PTAWI  distribution 
A  random  variate  from  PTAWO  distribution 
Unadjusted  fraction  of  vessel  tonnage  to  be 
loaded  at  port  I 

Unadjusted  fraction  of  vessel  tonnage  to  be 
unloaded  at  port  I 

Final  fraction  of  vessel  tonnage  to  be  loaded 
at  port  I 

Final  fraction  of  vessel  tonnage  to  be  unloaded 
at  port  I 


The  calculations  are  carried  out  as  follows  for  a  vessel  passing 
through  Welland: 

Let  A  be  the  set  of  ports  on  the  itinerary  above  Welland. 

Let  B  be  the  set  of  ports  on  the  itinerary  below  Welland. 
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BI  =  1-AI 


BO  =  1-AO 

PON (I)  =  SVTO(I)/PCBF(I)  IeB 

POFF(I)  =  SVTI(I)/PCBF(I)  I  £  B 

TN  =  BO/  ~  PON  (I) 

IEB 

TF  *  BI/  /  POFF(I) 

IeB 


PN(I)  =  TN*PON (I)  IeB 
PF(I)  =  TF*POFF(I)  IeB 
PON (I)  =  SVTO(I)/PCAF(I)  I  e  A 
POFF(I)  =  SVTI (I)/PCAF (I)  I  e  A 


TN  -  AO/ PON  (I) 

IeA 

TF  =  AI/  H  POFF(I) 

IeA 

PN(I)  =  TN*PON (I)  IeA 

PF(I)  =  TF*POFF  (I)  IeA. 

Note  that,  in  general,  cargo  is  both  loaded  and  unloaded  during  any 
stop  on  an  itinerary.  No  port  appears  twice  on  any  itinerary.  For  all  but 

the  western-roost  port  on  an  itinerary,  the  decision  must  be  made  as  to 

whether  the  stop  should  be  made  on  the  way  in  or  on  the  way  out.  This 

determination  is  made  by  a  very  simple  rule:  If  more  is  to  be  unloaded 

than  loaded,  the  stop  is  made  on  the  way  in;  otherwise,  it  is  made  on  the 
way  out.  This  rule  assures  that  a  vessel  is  never  loaded  over  its  capacity. 

The  thrust  of  all  of  the  foregoing  detailed  calculations  and  explana¬ 
tions  is  that  care  must  be  taken  in  order  to  provide  itineraries  that 
reflect  the  observe  movement  patterns  of  saltwater  vessels  in  the  GL-SLS 
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system  and  at  the  same  time  provide  the  required  mix  of  cargo-carrying 
capacity  to  move  goods  in  and  out  of  the  ports.  Following  is  a  user  manual 
which  describee  in  detail  the  inputs  and  outputs  associated  with  the 
itinerary  generation  program. 


B.  USER  MANUAL 
1.  Introduction 

All  data  inputs  for  this  program  are  in  fixed  column  formats.  Several 
probability  distributions  are  required,  so  that  a  few  words  about  their 
input  format  are  in  order.  The  data  are  arranged  as  follows: 


Card  1 

Columns  1-8 

Key  word.  This  key  word  specifies 
which  distribution  follows. 

Cards  2-n  +  1 

Columns  1-10 

Right-justified.  Value  X. 

Columns  11-20 

Right-justified  100  x  the  probability 
of  observing  the  value  X. 

Card  n  +  1 

Column  10 

Zero. 

Column  20 

Zero  (signals  the  end  of  the  data 
for  this  distribution). 

Consider,  for  example,  the  following  set  of  data: 
KEXAMPLE 


7 

20 

11 

25 

12 

10 

19 

30 

176 

15 

0 

0 
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The  random  variable  indicated  by  the  key  word  KEXAMPLE  is  distributed 
such  that  it  takes  the  value  7  with  probability  .20,  11  with  probability 
.25  and  so  on.  Note  that  the  sum  of  the  values  in  the  second  field  must 
equal  100.  Also,  a  key  word  may  have  fewer  than  8  non-blank  characters. 
The  number  of  discrete  values,  n,  for  any  distribution  may  vary  between  1 
and  100,  inclusively. 

2.  Input  Data  Stream 

All  numbers  should  be  right-justified  in  the  indicated  fields.  If 
the  indicated  format  is  "I",  no  decimal  point  is  allowed.  If  the  format 
is  "F",  a  decimal  point  may  be  punched  anywhere  in  the  field.  The  user 
should  keep  in  mind  that  in  all  cases,  both  leading  and  trailing  blanks 
are  interpreted  as  zeroes.  An  "A"  format  signifies  alphabetic  data. 


Card 

Columns 

Format 

Description 

1 

1-10 

I 

The  number  of  itineraries  to  be 
generated. 

2 

1-10 

F 

The  probability  of  selecting  Branch  1 
given  that  the  vessel  is  to  pass 
through  Welland. 

3 

1-5 

A 

PDATA:  key  word  indicating  that  the 
port  data  cards  are  to  follow. 

11-20 

I 

Number  of  ports. 

21-30 

I 

Number  of  the  first  port  above  Welland 

4 

1-10 

I 

Port  number.  Ports  must  be  numbered 
in  the  following  sequence,  uniquely 
and  skipping  no  integers:  (a)  Branch 
ports  from  west  to  east,  (b)  Branch  2 
ports  from  west  to  east,  (c)  all  other 
ports  from  west  to  east. 

11-20 

F 

Total  inbound  salt  vessel  tonnage  for 

this  port. 
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Card 

Columns 

Format 

Description 

21-30 

F 

Total  outbound  salt  vessel  tonnage 
for  this  port. 

31-40 

I 

Branch  number  for  this  port.  Zero 
if  the  port  lies  on  neither  Branch  1 
nor  Branch  2. 

N  +  4 

1-8 

A 

Key  word  for  probability  distribution. 

N  +  5  on 

1-10 

I 

Value  X  (Zero  in  last  card). 

11-20 

I 

100  x  probability  of  value  X.  (Zero 
in  last  card) . 

Each  of  the  4  distributions  described  below  is  entered  sequentially 
in  the  preceding  format. 

Last  1-6  A  ENDATA.  Key  word  signifying  the  end 

of  the  input  data  stream. 


Probability  distributions: 


Key  Word 
NPBW 

NPBW1 

NPAW 

PTAWI 


Description  of  Distribution 

The  number  of  ports  below  Welland  on 
an  itinerary  in  which  the  vessel  passes 
through  Welland. 

The  number  of  ports  (all  below  Welland) 
on  an  itinerary  in  which  the  vessel 
does  not  pass  through  Welland. 

The  nunfoer  of  ports  above  Welland  on 
an  itinerary  in  which  the  vessel 
passes  through  Welland. 

The  percentage  of  a  vessel's  inbound 
tonnage  that  it  unloads  above  (as 
opposed  to  below)  Welland,  given  that 
the  vessel  passes  through  Welland. 

The  values  are  percentages .  not  fractions 


These  distributions  may  be  entered  in  any  sequence. 


Outputs 


The  primary  output  consists  of  the  itineraries,  written  to  file 
number  1.  Also,  the  following  information  is  written  on  file  6: 

1.  The  calculated  probability  of  passing  through  Welland. 

2.  For  vessels  passing  through  Welland,  the  expected  fractions 
of  inbound  and  outbound  tonnage  transferred  above  Welland. 

For  the  generated  itineraries: 

3.  Percent  of  vessels  that  passed  through  Welland. 

4.  Distributions  of  the  number  of  ports  of  call 

(a)  above  Welland  for  vessels  that  passed  through 

(b)  below  Welland  for  vessels  that  passed  through 

(c)  for  vessels  that  did  not  pass  through 

(d)  for  all  itineraries. 

5.  The  number  of  subitineraries  generated. 
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CHAPTER  13.  EDB  PROCESSING  PROGRAM 


A.  PROGRAM  DESCRIPTION 

This  program  is  written  in  FORTRAN  and  is  used  to  process  the 
"experience  data  bank"  (EDB)  generated  during  an  EDB  simulation.  In 
NETSIM  II,  a  vessel  confronted  with  a  choice  between  two  or  more  parallel 
routes  to  the  same  destination  selects  the  route  with  the  lower  expected 
transit  tine.  In  order  to  establish  the  criteria  for  estimating  such 
expected  transit  times,  an  EDB  simulation  run  is  made  in  which  the  parallel 
route  selections  are  made  randomly  and  resulting  transit  times  are  recorded 
along  with  certain  usage  parameters  which  describe  the  state  of  the  route. 
The  EDB  processing  program  processes  these  records  and  arranges  the  usage 
parameters  for  each  parallel  segment  with  their  associated  vessel  transit 
times  so  that  they  can  be  input  directly  to  statistical  analysis  (such  as 
a  canned  regression  program) . 

Following  is  a  user  manual  which  describes  the  program's  inputs  and 
outputs  in  detail. 

B.  USER  MANUAL 

1.  Input  Data  Stream 

All  values  must  be  right-justified  in  the  indicated  fields.  The  user 
should  keep  in  mind  that  all  leading  and  trailing  blanks  are  interpreted 
as  zeroes. 
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Card 

M 

l 


2 


Columns 

1-2 

4-5 


7-8 


10-14 

16-17 

19-20 


1-4 


6-9 


Description 

The  total  number  of  parallel  routes  in 
the  simulated  system. 

Identification  number  of  the  highest 
numbered  lock  (same  as  HI. LOCK  in 
NETSIM  II). 

Identification  number  of  the  highest 
numbered  reach  (same  as  HI. REACH  in 
NETSIM  II). 

Total  simulation  time  in  minutes. 

A  code  set  to  1  if  the  output  is  to  be 
punched  on  cards,  0  otherwise. 

The  input  device  number  for  the  NETSIM  II 
EDB  records. 

The  identification  number  of  the  ending 
upstream  facility  (lock,  reach,  lake, 
etc.)  on  the  route. 

The  identification  number  of  the  ending 
downstream  facility  on  the  route. 

There  will  be  one  type  2  card  for  each 
parallel  route  in  the  system. 


The  EDB  records  from  the  NETSIM  II  EDB  simulation  must  be  supplied 
through  the  input  device  whose  number  is  given  in  cc  19-20  of  card  type  1. 
This  device  could  be  a  magnetic  tape,  card  file,  etc. 


2 .  Outputs 

The  only  program  output  consists  of  a  series  of  records  as  follows:. 

Card 

Type  Columns  Description 

1  1-4  Vessel  identification  number. 

5-8 


9-12 


Vessel  length  in  tens  of  feet. 

Vessel  transit  time  through  the  route 


Card 

M 


2 


Columns 

13-14 

15-16 

17-18 

19-20 

21-22 

23-24 


Description 

Route  number  (in  the  order  as  input). 

Vessel's  direction  (1  =  downstream, 

2  ■  upstream). 

Number  of  entries  on  this  record. 

1st  usage  parameter. 

2nd  usage  parameter. 

"3rd  usage  parameter 


79-80 

31st 

usage 

1-2 

32nd 

usage 

3-4 

• 

33rd 

usage 

• 

• 

37-38 

50th 

• 

• 

usage 

parameter  (if  necessary) . 
parameter  (if  necessary) . 
parameter  (if  necessary) . 

parameter  (if  necessary). 


The  program  allows  up  to  50  parallel  routes  and  50  usage  parameters 
per  route.  The  usage  parameters  are  as  follows: 


For  a  lock  i)  near  queue  size  li)  far  queue  size 
For  a  reach  i)  number  of  vessels  in  reach. 

The  usage  parameters  are  listed  in  the  order  of  facilities  as  input 
to  NETS1M  II  in  the  parallel  facilities  table.  The  reason  for  having  up 
to  50  parameters  is  that  a  route  may  contain  many  locks  and  reaches.  If  a 
route  contains  a  lock,  a  reach  and  a  lock,  for  example,  there  will  be  a 
total  of  five  parameters  given  in  the  order  of  the  facilities.  That  is, 
cc  19-20  in  card  type  1  will  contain  the  near  queue  size  for  the  first  lock, 
cc  21-22  will  contain  the  far  queue  size  for  the  first  lock,  cc  23-24  will 
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contain  the  number  of  vessels  in  the  reach,  cc  25-26  will  contain  the 
near  queue  size  for  the  second  lock,  etc. 
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APPENDIX  D 

PROGRAM  IMPLEMENTATION 


This  appendix  is  offered  as  a  rough  guide  to  the  programmer  who  must 
oversee  the  details  of  implementing  the  NETSIM  II-PROSIM  package.  Specific 
machine  considerations,  core  requirements  and  compile  time  are  discussed 
in  the  following  sections.  Auxiliary  input-output  device  requirements  are 
very  modest,  as  has  been  mentioned  previously  in  this  publication.  A 
system  with  a  card  reader  and  two  or  three  tape  drives  should  serve  the 
purpose.  No  discussion  is  given  of  execution  time  since  it  is  so  variable 
with  system  characteristics,  run  parameters,  congestion,  etc.  Let  is  simply 
be  said  that  for  a  large  system,  computer  run  time  can  be  "considerable.” 


A.  MACHINE  FORMAT 

The  two  main  programs  in  the  package,  NETSIM  II  and  PROSIM,  are 
written  in  SIMSCRIPT  II. 5.  Thus,  the  most  immediate  consideration  in 
selecting  a  computer  is  whether  a  SIMSCRIPT  II. 5  compiler  is  available 
for  that  computer.  If  a  different  version  of  SIMSCRIPT  is  available,  some 
program  modification  may  be  required. 

The  internal  data  representation  within  the  machine  is  also  to  be 
considered.  The  programs  were  developed  for  the  IBM  System  360  or  370 
which  use  words  consisting  of  eight-bit  bytes.  This  format  has  affected 
the  data  packing  within  the  programs.  For  example,  variables  that  are 
packed  into  one-quarter  of  a  word  cannot  exceed  a  value  of  127.  Those 
that  are  packed  into  one-half  of  a  word  cannot  exceed  32,767.  If  the 
machine  to  be  used  has  smaller  quarter-words  or  if  quarter-words  cannot 
be  addressed,  the  data  packing  (in  the  preambles  of  the  two  programs)  will 
have  to  be  altered. 
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The  auxiliary  programs  in  the  simulation  package  are  written  in  IBM 
level  G  FORTRAN.  One  difficulty  that  could  arise,  even  with  other  level 
G  compilers,  is  that  the  programs  may  reference  subroutines  that  are 
resident  in  the  PSU  FORTRAN  library  but  are  not  found  in  other  FORTRAN 
libraries.  For  example,  the  itinerary  generation  program  calls  a  function 
RAND(X)  which  returns  pseudo-random  numbers.  If  such  a  routine  is  not 
supplied  by  the  system,  it  will  have  to  be  programmed  and  compiled  with 
the  itinerary  generation  program. 

B.  CORE  REQUIREMENTS 

Core  memory  requirements  in  both  NETSIM  II  and  PROSIM  vary  according 
to  the  size  of  the  system  being  simulated.  Following  are  formulas  which 
estimate  the  core  requirements  on  an  IBM  OS/370  system  for  each  of  the 
programs.  Estimates  are  given  in  bytes. 

1.  NETSIM  II 

Bytes  -  126,000  +  220A  +  4B  +  64C  +  124D  +  216E  +  48F  +  100G 
+•  50H  +  8AB  +  2AF  +  F2  +  4A2B 

where 

A  -  number  of  ports 

B  m  number  of  commodities 

C  ■  nuntoer  of  vessels  (saltwater  and  bulk) 

D  m  number  of  lakes 
E  *  number  of  locks 
F  ■  number  of  nodes 
G  *  number  of  reaches 

H  ■  maximum  number  of  saltwater  vessels  in  the  system 
at  any  one  time. 
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As  an  example,  a  system  with  22  ports,  12  commodities,  1000  total 
vessels,  5  lakes,  10  locks,  50  nodes,  15  reaches  and  a  maximum  of  200 
saltwater  vessels  in  the  system  at  once  would  require  about  241,000  bytes. 


2.  PROSIM 

Bytes  =  211,000  +  344A  +  20C  +  40D  +  236E  +  52G 
where  the  variables  are  defined  as  above.  A  system  of  the  same  size  as  in 
the  example  above  would  require  242,000  bytes. 


C.  COMPILATION  TIME 

Compile  times  for  NETSIM  II  and  PROSIM  on  an  IBM  370/165  are  as  follows: 


CPU  seconds 


Elapsed  seconds 


NETSIM  II 


PROSIM 


Of  course  these  times,  especially  the  elapsed  times,  can  vary  somewhat 


from  one  compilation  to  another. 
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